I recently attended a 90 minute masterclass on the state of HTML5 by my colleague at Arc90, quintessential technologist Avi Flax. I assumed the spec was getting close to complete and it was going to finally give developers a non-moving target for writing code that modern browsers support. I was shocked to find that today HTML standards are still a contentious and equivocal subject.
In 2004 an org called WHATWG was founded by people from Apple, Mozilla, and Opera in reaction to perceived bad strategy and decision-making at W3C regarding the future of HTML standards. They wanted to take standards planning out of the glacial world of bureaucratic approval processes and put it on the fast track. It seems they had some success, as the W3C eventually adopted the WHATWG work as the starting point for their HTML5 spec. Of course it couldn’t be that simple, as they now both maintain independent HTML specs. The W3C continues to target a massive, multi-year “HTML5” spec whereas WHATWG has adopted an incremental approach, what they call a “Living Standard“.
It struck me that the WHATWG’s rejection of massive milestones mirrors the Continuous Integration approach that has been gaining traction on the development side of the software field. Continuous Integration puts an end to software releases that take months or years to plan and execute because there is so much opportunity for the various parts-in-progress to become incompatible, or for the business needs driving the release to change. By releasing a new version monthly and keeping tight controls to make sure everyone is keeping their piece in sync, working software becomes a reality and the risk of becoming a pipe dream is minimized.
I imagine that applying this approach to HTML specifications has many of the same benefits, and in some ways is even more important. When it takes years to produce a spec critical to the roadmaps of browser creators, they are each forced to make ad hoc decisions on how to move their technology forward. To wait means losing the competitive edge. A spec with a rapid, iterative approach has a greater chance of actually getting implemented, and that means countless web developer hours saved from the hell of browser incompatibility. Of course, care must be taken to not neglect the strategic direction of the spec and the ability to make revolutionary changes. But I think the long journey to major changes can still be made with small, sure steps.