As you're probably aware, progress on the development of new specs within standards bodies like the W3C moves at a glacial space. The reasons for this are numerous, but mainly boil down to some combination of internal politics, a general lack of direction (because they, the standards bodies, are having to guess not only what we, authors, want, but also how we want to go about describing what we want in code), and the need for reference implementations. With everything else on the web moving so quickly, the fact that our standards aren't keeping pace is problematic. And I don't think any of us want a return to the browser wars, when innovation was taking place solely on the implementation side. So where do we go?
I look to the Microformats community as a great example of what to do in a situation like this. If you look back in the history of HTML, you see that a lot of what has come out of the Microformats camp is implementations of concepts originally proposed in early drafts and discussions around HTML. Two perfect examples of that are how we mark up people and figures, both of which were proposed in HTML 3, but never made it into the final HTML 3.2 spec. The first example is the
person element, which surfaced much later in the far superior hcard microformat. Similarly, HTML 3 proposed a construct for figures that included the image as well as caption and credit information; that was resuscitated in the figure microformat and has, since, even found its way back into the standard as part of the draft HTML 5 spec.
-moz- you see before
Over the last few years, I built upon the knowledge I gained in my experiments and began working on a mechanism to allow extensions like this to be created with very little effort. The idea evolved into an "enabler" library that gave you hooks into a page's CSS and facilitated the creation of whatever extensions developers wanted. They could be aimed at a production environment or simply be created as reference implementations of features they wanted to see added to CSS. And so eCSStender was born. The wonderful side-effect of building eCSStender is that the very same logic that was used to enable extensions to CSS could also be put into use patching the holes in a browser's implementation of CSS. So, for instance, say you want to use a selector such as
tr:nth-child(even) td in IE6; traditionally, the properties set using this selector would be ignored by IE6 as it doesn't understand the selector, but, with eCSStender, developers have fixed that issue and your style rules will Just Work™.
The overall goal of the project is to enable developers to generate the patch files or extensions they want and then aggregate those extensions in one place (much like the jQuery UI Library) and make them available for designers who, in turn, just include eCSStender.js and the extension sets of their choosing and can write their CSS to modern specs (or forthcoming or even proposed ones) and have the library turn their instructions into reality. I like to think eCSStender does for CSS what microformats have done for HTML. By leveraging the built-in extensibility of these languages that the W3C has given us, we can create the future we want and then let the spec writers codify the best ideas we generate into the spec.