About eCSStender

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.

So I guess where I'm going with all of that is that I think we (with all due respect to Gandhi) need to be the change we want to see on the web. We are all vendors and we shouldn't be afraid to take the reigns and build a fully-functioning proposal for how we want to see CSS or HTML or JavaScript change. But before I go into how eCSStender fits into all of this, let me take a step back and cover how the idea for eCSStender came about.

Back in 2005, after being somewhat dissatisfied with the JavaScript hoops designers had to jump through to implement sIFR, I started playing with the concept of writing new CSS properties through the use of vendor-specific extensions (e.g. the -moz- you see before -moz-border-radius) and using JavaScript to make those extensions actually do something. In early 2007, I debuted my first decent example of this at Web Directions North: a scheme for generating presentational Flash into the document from your style sheets. It floored a number of people at the conference, including the folks from Adobe, but I was never really happy with the final product, so I went back to the drawing board.

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.

Aaron Gustafson,
2009-04-27