Whither W3C? | June 17, 2007
I’ve been a strong proponent of web standards since first being introduced to them back in 2000 by Jefrey Zeldman. I started discussing standards on my local mailing list, then on my blog, and finally at conferences and events. I even wrote a book on the subject.
Over the last seven years I’ve seen web standards go from relative obscurity to industry best practice. Browser support is now extremely good, and I can’t remember the last time I saw a job advert for a front-end developer that didn’t require a thorough knowledge of CSS. We no longer talk about them with such fervour on our blogs or at web conferences, preferring to talk about design, typography or user experience instead. Like all good standards, they have started to become invisible.
This invisibility is partly due to their widespread adoption. However it is also down to their slow rate of change. A few years ago we were seeing new CSS techniques appearing almost weekly, as developers tried to push the boundaries. However we’ve now reached a plateau with what can be achieved with the existing technologies, and need to look towards the future. Towards the people building the next generation of web standards.
The W3C has come under quite a bit of criticism of late for the slow development of CSS3, the wrong direction it took with XHTML2.0, and the mess it made with WCAG2.0. High profile developers have called into question everything from the organisational structure and decision making process through to the lack of transparency and the way it engages with the wider community.
To help address these issues, several people have set out on their own paths with greater or lesser success. As a response to the bloated and unworkable XHTML2.0 specification, the WHATWG set out to create something more relevant for today’s web application developers. Operating as a benevolent dictatorship, the WHAT working group was open to the views of the community, while managing to avoid getting bogged down in endless political discussions. While I’m not sure the model could work for other projects, the results have been pretty impressive. The working group has now become an official W3C working group, and the draft specification has been renamed HTML5.
Unlike other W3C working groups, anybody can join the official mailing list as an “invited expert”. From what I understand the list is very highly trafficked, and the technical level of the discussion is quite difficult to follow by your average web developer. However this willingness to engage seems to be baring fruit, and many of the less palatable ideas like reserved class names have been dropped. Apart from the working groups insistence on keeping the font element, everything else I’ve seen has been pretty impressive so far. In a recent post, Ian Hickson suggested maybe doing the same for CSS.
Taking a different approach was Joe Clark and his WCAG Samurai. A relatively secretive group of individuals, the Samurai were tasked with amending the existing web content accessibility guidelines. These guidelines were written a very long time ago and have been showing their age for years. With WCAG2.0 in development hell at the time, amending the existing spec seemed like a very sensible idea. The resulting guidelines have recently been published along with two “blind” peer reviews. While I doubt WCAG1.0 +Samurai will ever become an official guideline, it makes a lot of sense on first examination and I applaud Joe for his persistence and hard work.
I’m not sure if WCAG1.0 +Samurai has had any affect on the official accessibility working group, but they seem to have addressed most of the original concerns with WCAG2.0 which is very positive.
My own personal bugbear is CSS3. We’ve been waiting for CSS3 now for seven years, and while some of the modules are nearing completion, others may never see the light of day. I’ve listened to a lot of the arguments why CSS3 is taking so long, and I do understand. It is a very complicated project being developed primarily by volunteers, so is bound to take time. One of the most illuminating articles on the subject comes from invited expert, Elika Etemad, and is well worth a read.
I recently proposed an interim specification called CSS2.2 which would include all the CSS3 selectors, properties and values that had at least one existing browser implementation. This would include things like multiple background images, border images, border radius, web fonts, text shadows, box shadows and multi column layout.
By concentrating on already implemented features, this should be a relatively easy specification to produce. The documentation has already been written for CSS3, and the test cases and implementations are in place. Any extra work that needs to be done on these new features will need to be done for CSS3 anyway, so it seems like the job is more editorial than technical. Unless I’m missing something crucial it should be as simple as transposing these new features into the completed CSS2.1 spec and creating a new point release.
This interim spec would then give browser vendors something to aim for, and provide developers with the features we need to innovate. We could then start thinking about what new, as yet to be implemented features we’d like to see in a future point release. This would make the whole standards process much more iterative and get the popular or easily implemented features out in the wild faster.
Reaction to the idea seems largely positive. Most of the developers I’ve spoken to welcome the idea of an interim specification, and I was pleasantly surprised to hear Hakon Lie promoting the concept at both Reboot and @media London. In fact, it seems to have provoked some interesting discussions inside Opera. I’ve also had people contact me suggesting we start up some kind of grassroots movement to promote the idea of CSS2.2 or even draft a specification ourselves. However specification writing is a complicated process that requires specialist skills, so is best left to the experts.
I’ve heard that reaction inside the CSS working group is mixed, but with a closed internal mailing list and little in the way of external communication, it is very difficult to tell what they are thinking. They recently launched a new blog to help improve communication, but the first post doesn’t fill me with confidence.
The argument I always hear from the W3C is, “if you want to get involved, you should join one of our public mailing lists”. However this seems more like an avoidance strategy than a real desire to communicate. The W3C must know that signing up to a high traffic technical mailing list provides just enough of a barrier to entry to put the majority of people off. I actually joined their CSS mailing list a few years back, but quickly left after every suggestion I made was brushed off with instructions to check the archive or read a three year old thread.
Mailing lists may still be popular amongst academia, but I think it shows a distinct lack of understanding about how people use the web these days. Rather than being critical about people posting their thoughts to their blogs, if the CSS working group really want to elicit feedback they should embrace the developer community. Do what the WHATWG does and set up watchlists for common terms like CSS3 or CSS2.2, post regularly to their blog and set up an official wiki. If the CSS working group really want feedback, they need to start by offering more transparency and make it easier for people to contribute.
Posted at June 17, 2007 6:19 PM