Simply defining, a conversion engine is tool that one uses to convert one form of text into another. Here, I am talking about converting plain text to formatted coding. If you want a better idea of what I am talking about, take a look at the excellent Markdown text-to-HTML engine. That is what I use to write my posts, and I highly recommend it to anyone who hates filling up their article with < and >s to make them look good.

Conversion engines are amazing because all the changes happen behind the scenes. What we get to see is what we’ve written in our own special formatting (defined by the engine), and what comes out is perfectly coded text. When we come back to edit, we see it the way we left it. It increases readability and usability. You don’t need to know any code to use such engines, but still get the desired output. Of course, a text-to-HTML engine is a rather measly thing (a rich-editor can do the same), but it’s the concept that is so interesting.

I am beginning work on a CSS-engine, which will take specially formatted plain text document, and output W3C valid CSS. This will be my first time writing a parser of any kind, so I am expecting to run into a lot of hurdles and over-night coding sessions. But the outcome will be worth it, in the form of knowledge, and my first major mass-use project.

I picked CSS as the output because it is the second most repetitive markup that I’ve come across (HTML being the first. Damn you angled brackets!). People sometimes end up defining the same styles for the same elements in multiple classes, which adds to bloat and also throws validation errors. There are things like colours and sizes which need to be re-used, but since CSS offers no system of variables and constants, the tedious look up process is annoying. Compression is my last and most important goal. Just like packed JS files are all the rage, I want to try and reduce the file-size of parsed CSS as much as possible. This will be mostly achieved by grouping declarations, removing white-space and unsupported attributes from element selectors. The result will be well formed and very small CSS output, while keeping your side of the style easy to decipher and change in the future.

I will release a pre-development documentation which will contain all the formatting details, limitations, and specifications in the coming days. I plan on documenting the process, for both self-notes and future reference for anyone wanting to embark on the same journey. Wish me luck!