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 flowmodel 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
Forwardevents 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 sagabugs. I'm looking forward to closing
them with tiny HTML stakes to the heart.