tantek.com

CSS 2.1 and CSS3 Color become W3C Recommendations – A Few Open Web Standards Practices Learned

on (ttk.me b/4CE1) using BBEdit

Developing good open web standards is more often than not an arduous, tedious, extremely detail oriented, and quite unglamorous task - it's work that typically induces blank stares when provided as an answer to questions like: "What do you do?" or "What do you work on?".

The moments of recognition for open web standards are few and far between, and thus it's important to take note when those moments occur. This is one of those moments: Cascading Style Sheets Level 2 Revision 1 (AKA CSS 2.1) and CSS Color Module Level 3 (AKA CSS3 Color) have finally become W3C Recommendations.

Each and every person who edited, contributed, wrote test suites, ran test suites, wrote implementation reports and perhaps most importantly, diligently interoperably implemented these standards deserves significant kudos for helping advance the open web. And along the way to the CSS 2.1 Recommendation, the CSS Working Group learned, developed, and adopted a number of open standards practices that as a set may prove to be far more valuable to the future of the open web than any one specification.

I don't think I had any idea what I was getting into, nor how it would shift the course of my professional career when Chris Wilson suggested to me just over 13 years ago that I join the W3C's Cascading Style Sheets Working Group (then actually known as "CSS&FP" - The FP for Formatting Properties) as Microsoft's Alternate Representative. In May of 1998 I attended my first CSSWG meeting (first open standards community meeting of any sort, W3C, etc.) in Paris, France hosted by Daniel Glazman of EDF. It felt like I was participating in some sort of geeky international congress (still kind of does actually).

Two months earlier, in March of 1998, CSS 2 had become a W3C Proposed Recommendation (PR) which meant that it was considered "done" and was simply awaiting a procedural W3C member review and vote. For all practical purposes, nothing else was going to get fixed in CSS 2. There wasn't a Candidate Recommendation (CR) phase back then, as evidence by the fact that no-one (including my Tasman team as part of Microsoft Internet Explorer 5 for the Macintosh) was able to implement CSS 2 as specified. The problems in CSS 2 were far more severe than mere errata - we had to develop a full revision to fix it.

It took us, the CSS working group, four years to produce the Last Call Working Draft of CSS 2.1, the publication thereof which was part of my first blog post. And that was merely the first of many so-called "Last Call" working drafts, which served to convince me that the very concept of a "Last Call" was fundamentally flawed - but that's a subject for another post / discussion on pragmatic specification stages.

The long and exceptionally challenging path to CSS 2.1 interoperability (several cycles of extremely thorough diligent testing, editing, iterating) among other things has taught us some key things. First, that holding a web standard to openly published test suites which are interoperably implemented by web browsers is absolutely essential for practical, pragmatic standards that are usable on the web, rather than hopes and ideals of what could be (what most published "standards" appear to be). However, second, it's also taught us that it can take a long time to be that thorough with something that large.

From the first CSS 2.1 Last Call Working Draft to Recommendation it took the working group nearly nine years. When Ian Hickson estimated it will take til 2022 for HTML5 to reach Proposed Recommendation, it wasn't unreasonable: that's 10 years from next year (2012), when HTML5 is now expected to reach Candidate Recommendation. And HTML5 is much more complex than CSS 2.1.

This is also why the CSS Working Group chose to modularize CSS for CSS3 - which also took several iterations of editing, implementing, remodularizing to help figure out where pragmatic boundaries could be drawn. Modularization is one of those things that can seem both reasonable and straightforward in theory, but in practice, be quite challenging. The CSS Working Group has made progress with understanding practical modularity, as evidenced by several CSS3 modules having already reached Candidate Recommendation status, and reasonably well implemented in browsers.

However I'd like to close this post with what I think is the more important set of lessons, expanding the first learned point above. In particular over the past 10+ years that it took us to make CSS 2.1 real, we've learned the following practices are strongly effective ingredients for open standards development. Some/many/most of these practices are not (or no longer) unique to the CSS working group, but it's one key group at W3C that's implemented them all and did so quite early on.

Open Web Standards Practices

In my opinion, as of 2011, if you want to develop open standards, especially open web standards, you must at a minimum follow the above practices. I'll expand on why and patterns that have emerged in a subsequent post.

CSS 2.1 is a tremendous achievement and everyone who worked on it, implemented it etc. should be very proud for this key building block of the open web platform. But we've gotten a lot more than CSS 2.1 in the years it took to develop it - the deliberate open standards practices that have emerged from that effort (among others) are perhaps even more valuable, as they can inform and improve every other open web standards effort that we pursue, as long as we deliberately choose to do so.

View on Twitter
♥ Like ♺ Repost ↵ Reply