What is wrong with Web Standards today
If the last few days of activity in the blog-sphere have shown web developers anything, it’s that the issues surrounding the development of web standards are much more complex than the simplistic understanding many of us seem to have had up until now. A lot has been said on the topic, so much so that I have trouble keeping it all in my head. After pouring over blog posts, and sifting through (and contributing to) so many comments, it’s perhaps worth taking a step back and figuring out what all of this has been about. (To clarify the title, Web Standards are fine, great in fact. The problem I want to address is what’s wrong with how new ones are being developed.)
The Lowest Common Denominator problem
The ultimate problem is a simple one: in our industry web designers have to code and design for the lowest common denominator. That’s nothing to be surprised about, but it happens to be the fact from which all other problems aired recently descend. So lets be very clear about why this ‘develop for the lowest common denominator’ practice is the reality we are faced with.
The web has all sorts of websites on it, there’s a site for anything you care to imagine (and some things you’d not), but broadly speaking all of these websites can be categorised into two camps: corporate and non-corporate. Site’s that exist to make money for someone, and sites that don’t. And it’s the site’s which generate money for people that make the internet possible - if the web did not create revenue streams there wouldn’t be the investment in the web that allows it to function as we know it today.
While non-commercial sites are perfect places to get experimental (for example on personal websites), corporate sites can not afford the same luxury. These sites must work correctly and look ‘right’ for everyone, regardless of their browser. That’s because visitors = revenue. Whether that be a direct relationship (e.g., visitor purchases goods) or something more obscure (e.g., visitor numbers = advertisement revenue), the reality is that a visitor has monetary value. When a visitor has a monetary value there is a literal price to pay when a website does not work, or displays incorrectly - that visitor walks away, more than likely going to the competition. So, if we develop for reasonably modern users with reasonably modern software, even were such users to make up 80% of the target audience, doing so breaks the experience for that bottom 20%. Our choice as designers and developers to use the ‘new shiny’ means we throw away big cash value. Corporations will not allow that to happen - and so, we all develop the sites that pay our wages to work properly for the lowest common denominator and up.
Why this is a big problem for us
It creates lag. If a Web Standard is released and it takes a year for browser vendors to implement the standard (a wishful thought) that doesn’t mean we can all start using the new standard next year. We have to wait for that standard to become available to the lowest common denominator before we can use it as intended anywhere other than in personal projects. Which is where the major problem is at the moment - the lag is so extreme that to all intents and purposes we are in the same situation now as we would have been if the W3C had ceased to exist ten years ago. The technologies we can use now are the ones that were written a decade ago. A hell of a lot happens in a decade, the very nature of the web has changed completely - from what was essentially a document retrieval system, to a multi-media online/offline extravagansa. But we’re using the technology designed for the document-web to do it. If this were the rail-road industry it’d be like building mag-lev bullet trains using iron mongers and steam engines.
Why there’s so much lag is a complex issue, but one major causal factor is Microsoft’s past action of abandoning development of browser software. IE stopped at version 6 for a long time. The existing W3C specifications sat there promising new possibilities, but remained un-implemented, or badly broken in IE6, for years. IE7 is now out, and fixes quite a few things, so those ten year old standards are now properly supported in it (mostly). IE8 is due out next year, and we are all hoping it will fix the remaining issues and implement some of the ‘new’ specifications the W3C has half-finished in the meantime. But we’re still left with the lag. IE6 will be around for a long time yet - despite Microsoft’s best efforts at getting users to shift up to IE7 (and everyone else’s efforts to get them to use Firefox, Opera, or Safari).
The W3C’s role in our problems
The W3C is the group that sets the standards the web is built upon. It’s their job to ensure that what works in one browser will work in another. That’s worth saying again; their one and only job is to ensure that any single website will work in every current browser. This is achieved by the creation of a Standard. Traditionally standards are made by ‘blessing’ a technology which already has proven popularity or dominance. For the web, now, it’s about getting browser manufacturers to agree to develop their software in a way that the standard sets out. Adhering to standards is beneficial all round, it stops fragmentation of the web so that users don’t need to switch to IE to view their banking site, but switch to Safari to purchase from Amazon. It stops web developers needing to build the same website in two or three different ways for two or three competing browsers. It vastly reduces the cost of creating and maintaining a website for the same reasons. It helps the browser vendors because their users don’t complain that they can’t do the things they want with their browser. In short, standards are beneficial now for all the same reasons they have been in the past.
But when Microsoft went on holiday from the web, it left the W3C with a problem. How do you create new standards if the major player (owning over 95% of the browser market) isn’t interested in supporting them, or even in finishing support for the existing standards? Well, from there all sorts of things happened in the web and at the W3C, but the upshot is that the W3C has not produced a new, finalised, well supported specification in the last ten years. The one and only new standard to be released was XHTML2 - which was developed entirely by the W3C without input from anyone else (browser vendors, designers, developers - all ignored). Unsurprisingly that standard is getting utterly ignored by the browser vendors, designers, and developers. Because it doesn’t do what any of those groups want or need. In one potent example it’s made clear that you can’t develop a standard on your own and expect to have it supported by anyone else. You need the buy-in of all the people that are going to use and implement it.
XHTML2 isn’t the only web standard that’s been in development in those ten years - so has CSS2.1, CSS3, and HTML5. All of these projects include the browser vendors in the effort, and none of them are yet finalised or released.
Both CSS projects are produced, more or less, behind closed doors. The projects are being lead by browser manufacturers (who have vested interests in getting their own way - producing arguments and stalling tactics), and software engineers. There has been virtually no consultation with real-world designers and developers on what they would like to achieve with these new specifications until very recently, and even then no where near enough. As such, even once these new CSS standards are out, they are not going to be ‘all that’, girlfriend. There are plans for a CSS template system no designer seems to have ever wished for, but nothing in terms of declaring CSS constants and expressions, or of comprehensive typography control (which designers sure as hell do want). So, where XHTML2 is an example of how going it alone fails, CSS2.1 and CSS3 are examples of how to (take a decade to) produce reasonable but hardly exciting specifications that add a few new toys but don’t really satisfy the people that are going to use the specifications.
HTML5 is another lesson the W3C need to learn from. It came about largely because the browser vendors were so fed up with waiting for the W3C they took it upon themselves to start making a new HTML. Down that road lies Trouble, for all the same reasons that non-standard elements were Trouble in the past. So it forced the W3C to partner-up/absorb the HTML5 effort. Sadly, this again is being lead by software engineers. While HTML isn’t such a problem for creatives when being developed by software engineers (HTML isn’t about being creative, it’s about document structure and semantics), it is non-the-less a big problem when the progress made by activists in the past gets rescinded because browser manufacturers don’t feel the need to be beholden to established best practices and accessibility features. HTML5 is proof you can’t leave browser vendors to do it alone either.
Why all the ruckus?
Because of the reasons above, and a host of further, ever more intricate knock-on problems, there is a total lack of progress being made in the area of expertise the humble Web Developer exists in; and after ten years we are getting brassed off about it. Deeply annoyed that new tools still are not available, upset that tools promised for years are still un-usable or broken. Sick to death of seeming to be ignored by the movers and shakers that decide what tools we get to use and what those tools will do in the secret cabal of a closed Working Group; as though we don’t know what we need our tools to do and so have nothing to contribute. As though our input gained from experience in the field is worth less than their internal posturing and theoretical debates. The ruckus is caused because it is ever more obvious that the processes by which progress is supposed to be being made are not working, and never will work. We are angry that no-one is addressing any of these problems, or if they are the communication vacuum that exists around the W3C isn’t allowing us to know about it.
In conclusion
There are a myriad of problems at all levels of the Web Standards movement. From internal practices at the W3C, to terrible communication with the public; from browser vendor apathy, to browser vendor arrogance. But most of the anger at the moment I think comes from the ‘us’/'them’ attitude that seems to exist between web developers and the people who are responsible for the tools we get to use (one day…). It’s a lack of progress mixed with feelings of helpless isolation that has many of us hopping mad right now.
Fixing the problems in Web Standards is a complex and time-consuming problem in itself. A number of radical ideas have been suggested, but none that seem practical in isolation. Solving this is going to require group effort, from the community, from the browser vendors, from the W3C. I do feel bad for essentially ripping into the efforts of many dedicated people, without offering solutions to the problems I see. If I come up with any thoughts on solutions, I’ll blog them. In the mean time, I hope at the very least the little explosion in the blog-sphere has acted as a wake-up call for the W3C and the vendors. Stop ignoring the people that rely on what you do. Open up, let us help. Make it easier for us to do that.
Entry Information
- Posted:
- Tue, 18th Dec 2007 at 21:12 UTC
- Filed under:
- Tags: