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 answers 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 a 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 when 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
- open iteration. The CSS working group was among the first to publish and maintain public interim editor's working drafts. Anyone can browse the raw updates: dev.w3.org/csswg. I don't remember who started this convention at W3C, but I highly approve.
- open mailing list. The CSS working group decided quite some time ago to switch all CSS spec discussion from the member-only w3c-css-wg mailing list to the already public www-style mailing list. The member-only list is pretty much just used for administrivia now.
- open irc channel. Since as long as I know, the CSS Working Group has used irc://irc.w3.org:6665/css for teleconferences plus face to face meetings, and anyone can join in to lurk, offer commentary etc.
- open irc meeting logs. The CSS working group for several years now has published public logs of the IRC channel from meetings (teleconferences, face-to-face). This is one I personally pushed for, based on my experience with the utility of having public IRC logs for microformats.org.
- open wiki. The CSS working group was among the first at W3C to create an open wiki. It's on its own site wiki.csswg.org, created before wikis had really been adopted inside W3C. Again, something I pushed for (but I believe Elika implemented, got the domain, set it up etc.) based on my experience with wiki-based development on microformats.org.
- open test suites. Even with CSS 1, the the CSS working group produced open, freely usable online test suites. This seemed obvious thing to do to me at the time, but apparently was not something to be taken for granted in standards development, e.g. absent from typical IETF work. For example there was no public iCalendar (was RFC 2445, now 5545) test suite. Instead, implementers were expected to pay for and attend in person an Interoperability Test Event run by another consortium (not IETF). This isn't just history, there still is no online, public, free iCalendar test suite. But you're welcome to register for the upcoming October 3-5 2011 CalConnect Interoperability Test Event taking place in Prague, Czech Republic and pay over $2000 to participate. Just want to observe? That'll be $350. No joke.
- open implementation reports. Anyone is welcome to run an implementation through a CSS test suite and submit/publish an implementation report. After some degree of (minimal) verification it will likely get posted on the W3C's site, openly, viewable by all. Again, not to be taken for granted. Again in contrast, CalConnect Test Event Reports public reports
will not identify any participating organization with any particular set of results..
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.