The Flowing Standard
Looking at it in terms of rebounds, plot twists, nurtured healing and abandonment, love and betrayal, strife, toil, stunning victories, dispersions and last minute rallies the only thing that distinguishes HTML's history from a charts-topping teenage fantasy saga seems to be the lack of vampires. And even then, were vampires around I'm not sure we'd notice them for all the action. I am therefore very excited to join the W3C staff to work on HTML full time as part of the HTML editorial team, in the hope that I may bring my humble contribution to this living monument.
For all that the HTML adventure may be fun to watch with some popcorn though, one of my hopes is that heading forward all parties in the HTML community can move towards more effective debates about focused technical issues while resolving sources of dissent. In other words: less drama, more work.
To take an example, much has been said of the living standard versus snapshot standard approaches. It's a very big Web, and HTML is a very big part of it, so it should come as no surprise that here just as elsewhere different participants may have different requirements, habits, or preferences. Some seek a specification that is continuously improved in a tight feedback loop with the reality of usage and implementation; others look for anchors of stability at regular intervals in that continuous flow. Are those wishes incompatible? I'm not so sure — a process in which stable snapshots are made while a bleeding edge version is also available strikes me as oddly familiar. Yes: it's a vanilla software release strategy. So let's just do that: the many communities of the Web are contributing to the bleeding edge; W3C is also committed to also publish stable snapshots at regular intervals.
As has already been announced, the HTML WG has moved development of its various specifications to a GitHub repository. Over the coming weeks we will be detailing the way in which this repository is organised and used. The current plan revolves around adapting the well-known git flow model to specification development. Git's flexible and powerful branching model allows us to maintain multiple branches, some headed for stabilisation in view of a tested and reviewed release, others carrying more future-fetching features; this while remaining able to apply bug fixes across the board.
Additionally, this enables proponents of changes to these documents to put their specification-writing where their mouths are by cultivating their own feature branches and making pull requests when they are ready. Just like other projects, including contributions will require review (in this case from the HTML Working Group). Hopefully, we can keep the overhead of this to a minimum — details will be worked out shortly (and as always we welcome input).
This brings me to the next good practice which we inherit from software development: testing. I believe that technology should not be called standard — or even just stable — without sufficiently strong testing to support it. Over the coming months, the HTML WG will be ramping up its testing work. Testing is a great area in which to contribute, and so long as you enjoy breaking stuff with a devious vengeance it's far from being as tedious as hearsay would have it. So if you want to help break the Web (and then fix it), come test stuff! A great place to start is by attending one of the upcoming Test The Web Forward events if there's one in your area (I will be at the Paris one next month). And if no such event is coming to a place near you (yet), we'll be working with the TTWF community to make breaking your favourite browser as easy and playful as possible.
Naturally, those are just two of the high-level upcoming efforts from Team HTML. On a day-to-day basis a lot of what we're going to stay busy with is mostly bugs, bugs, bugs. Just like testing, this might not sound fascinating, but I for one am mightily excited: those are teenage fantasy saga bugs. I'm looking forward to closing them with tiny HTML stakes to the heart.