Web Standards Gone WildFeb 18, 2009 By Joshua Allen
I recently attended the excellent “Web Directions North” conference, and the opening keynote by Dan Connolly of the W3C really brought into clarity something that’s been gestating in my mind for
awhile now. Dan was editor of the original HTML 1.0 specification and began his keynote by explaining that he is a tinkerer who likes to look at
specs and read BNF — he then asked for a show of hands of people who can read BNF. Shockingly, only a few hands went up.
At first glance, Dan’s statements could be seen as a sort of boastful way of pointing out how “elite” he is. But I didn’t take it that way, and
Dan’s comments highlighted an important trend in our industry — that normal people are no longer comfortable reading specs. This is a tragedy,
IMO, and the blame rests squarely on the shoulders of specification authors.
The truth is, specs used to be a lot simpler, shorter, and cleaner. I implemented my own IP stack by reading RFC 791, and I implemented an HTTP
server shortly after RFC 1945 was first drafted. These are two of the most fundamental technologies upon which the modern Web is built,yet any
determined amateur can implement them by reading the simple specifications. In fact,I wrote my own implementations of most of the important
technologies in the early years of the web:
- Internet Protocol — 11,000 word spec
- HTTP 1.0 — 18,500 word spec
- HTML 1.0 — 10,000 word spec
- XHTML 1.0 — 7,000 word spec
- SOAP 1.0 — 7,000 word spec
Now contrast this with the HTML 5 specification, which is nowhere near being done, but
already more than 268,000 words! This is nearly 30x larger than the original HTML specification! The bar for someone to read the spec, let alone
implement it, is massively higher. Is it any wonder that people don’t bother reading specs these days?
This is a real tragedy, because it practically guarantees that only large organizations will have the resources to maintain software based on
these new specifications. It turns the democratic spirit of the web upside-down. As Dan said in his keynote, “Hixie sent out an e-mail and 500
people joined the HTML5 working group; a level of participation we’ve never had before”, and then went on to explain that many people drop off
over time after their initial enthusiasm. This anecdote illustrates the sea change perfectly. In the past, we had only 11 people on a working
group, but 500 people could quickly implement the spec. Now we have 500 people on the working group, but very few can implement the spec. Of
course, orders of magnitude more people can claim to have participated in a W3C working group, but is this really what we should be optimizing
And this, I think, gets to one of the root causes of this sea change. The people writing and implementing the early web specifications were
generally very practical people unconcerned with politics or egos. I can remember times that I e-mailed Jon Postel with questions about one or another of his specs, and he would reply quickly and to
the point — he was always gracious and pragmatic on mailing list exchanges, too. Yes, we all felt that “this Internet thing is going to be
BIG!”, but we didn’t have proof back then. People were working to solve technical challenges and bootstrap adoption, not to make personal names
for themselves or push an ideological viewpoint. This isn’t to say that spec authors today are all egomaniacs, but people today implicitly
understand that they might be the next Jon Postel, whereas Jon Postel didn’t ever entertain such thoughts, since he was in an unproven field.
Dave Winer made a similar point in a blog post yesterday. For
the most part, the OAuth specs are some of the cleanest, simplest specs to emerge in the past couple of years. But Dave makes an interesting
observation: “OAuth isn’t so hard once you got it working, but there are too many docs, too heavy on theory, and there is no validator … I
offered to help get the process systematized by remembering what it was like to be a newbie, which I still am, totally.” On the one hand,
OAuth is head and shoulders above other recent specs, because a determined newbie actually CAN implement the thing. But the “too heavy on theory”
part is right on, and other spec authors would do well to pay attention to this. Read any of the specs in the bulleted list above, and see if you
can find any signs of “theory”, “manifestos”, or other such nonsense. When someone reads your spec, they care about only 2 things: 1) What can it
do for me? and 2) How do I implement it?
Now, I wouldn’t go so far as to say that the standards process has never been politicized. Realistically, the standards bodies are just one
additional mechanism via which companies compete with one another. And I’ve seen plenty of politics play out in the standards bodies. But you
cannot argue with the Spartan clarity of the early specs, versus what comes out these days. Specs used to be clean and crisp — documents that
the enthusiastic newbie could use to build real software to solve real problems.
Finally, I completely understand that there are sometimes legitimate reasons for bloat. But we should look very critically at bloat and be aware
of what it’s costing us versus what we gain, before agreeing that it’s a good thing. The HTML 1.0 spec, at 10,000 words, is the HTML spec that
changed the world. No additional HTML spec is going to ever have that level of global impact again. At best, we can hope for some incremental
improvements. We were faced with a similar choice when XML 1.1 was proposed — we were being asked to add complexity for implementers in favor of
an incrementally improved standard, and we finally all realized “this is stupid, XML 1.0 is plenty good enough”. We killed XML 1.1, and it turns
out that nobody really complained. A proud moment for the web, if you ask me.
What do you think? Agree or disagree? We would love to see your opinions here in the comments section. And don’t forget to follow our twitter feed to be notified when new lab projects, articles, or opinions are posted.