May 31, 2008

CSS parsing

Posted in GSoC tagged , , , at 1:51 am by fadinlight

I think that, if someone had to ask me what’s the temptation I have to deal with the most, I would reply without any further thinking: “Reinventing the wheel!“. This is not so much evil, reinventing the wheel can lead to new improvement and new techniques, but it has a great enemy: time! 🙂

So, after I’ve spent some time trying to get some structure out of my demo and started building the library that will stay behind the frontend, I’ve begun writing a rough CSS parser, following my agreement with my mentor about starting with CSS instead of rules. After some minutes of working, I came in touch with an already beautifully written Javascript CSS parser. Even if the code has made public, I’m going to contact the author to see if there is any problem on including (crediting him) some of his code into mine.

However, after some adaptation to the code (some issues with DOM, the library supposed to work with innerHTML and I had to change that reading nodeValue from a childNode… or better, cycling all childNodes because of the Mozilla’s 4k bound limit for textNodes; some issues with regular expressions too), some structuring of my library and some UI tweaking in my old demo (just using that for debugging purpose), I’ve got this:

Here you can see an ordered list of CSS classes defined in the z17 t@h rule file. Clicking on one of those classes… here it is:

Let’s click on another class:

So, what about next steps?

The first thing I’ll do now is to code a little “CSS writer” to get the CSS back from the data model. This will be not enough, because a “blind” CSS writer would scramble the original code (as 80n already pointed out during community bonding phase), so some more tweaking on the original parser is probably needed. However, it will be enough to try some little interactivity, even if only modifying existing CSS classes and properties, and deliver a little screencast for the weekly report 🙂