Editing the W3C HTML5 spec
On 3 November, the Queen and Uncle Timbo (Sir Tim Berners-Lee to you) came round to Lawson Towers to threaten me with a punch in the face and a karate chop if I didn’t co-edit the W3C HTML5 spec.
So I said yes ”” they look pretty frightening, I think you’ll agree.
There’s a pretty groovy and diverse team, including Patricia Aas who works on the Vivaldi browser; my friend and ex-Opera Devrel colleague, Shwetank Dixit who lives and works in India for Barrier Break, an accessibility organisation; ex-Opera chum Sangwhan Moon; long-haired digital trouble maker who does “Open Standards at GDS” (Government Digital Service), Terence Eden; Xiaoqian Wu of W3C and Steve Faulkner of The Paciello Group, another accessibility organisation.
I’m currently advising Wix Engineering on web standards. As an independent consultant, I’m not representing Wix, but obviously any relevant lessons we’ve learned by open-sourcing our Stylable CSS for Components pre-processor will be fed back to the W3C Working Groups.
A lot of people have asked me why there are two HTML specs – the Living Standard at WHATWG, and the HTML5.x specs at W3C. What’s the difference? And which should you use? The answer: it depends. (Well, this is web development, after all).
Spec implementors (primarily, browser vendors) implement from the WHATWG spec. The painstakingly algorithmic WHATWG document is exactly what we need so that browsers implement interoperably. But it’s hard for web authors (the million or so normal folk worldwide who write HTML to make websites) to get advice on how best to write good HTML from the WHATWG spec.
I’ve long used Steve Faulkner’s excellent guidance on HTML and ARIA, for example. The WHATWG spec is a future-facing document; lots of ideas are incubated there. The W3C spec is a snapshot of what works interoperably – authors who don’t care much about what may or may not be round the corner, but who need solid advice on what works now may find this spec easier to use.
For example, the WHATWG spec talks of the outlining algorithm, whereby a heading element such as <h1> changes its “level” depending on how it’s nested in <article>, <section> etc. I wish this actually worked, because it’s useful and elegant. However, as the W3C spec says “There are currently no known native implementations of the outline algorithm in graphical browsers or assistive technology user agents” and so advises “Authors should use heading rank (h1-h6) to convey document structure.”
I believe the latter spec is more useful to people writing websites today.
I’ve got lots of friends in WHATWG and believe it when I wrote that the strength of the web over last 7 years has been due to WHATWG. In my opinion, the work that WHATWG did saved the Web from irrelevance, while the W3C went meandering around XML-land instead. I’ve discussed this with some friends in WHATWG and W3C, too, to canvas opinion. They told me HTML needs a cute little mascot, so I’m stepping up to the plate.
I don’t want the W3C and WHATWG specs to diverge in substantive matters, and hope that useful authoring advice we produce can make its way into both specs.
Vive open standards!
Buy "Calling For The Moon", my debut album of songs I wrote while living in Thailand, India, Turkey. (Only £2, on Bandcamp.)
4 Responses to “ Editing the W3C HTML5 spec ”
Thanks to you and the entire editorial team for stepping up for this critical task. Your post is great and I share your aspiration that we work hard to prevent divergence between W3C and WHAT WG.
Unfortunately this post contains a lot of inaccuracies. For example, the claim that the WHATWG HTML Standard is future-facing and for incubation is false. Such additions are explicitly against the WHATWG working mode: see the sections on Additions and New Proposals.
It also misunderstands the outline algorithm, which isn’t a requirement on browsers, but instead guidance for developers as to how to structure their pages. As such it’s not some kind of speculative feature as this post characterizes it. (It’s bad guidance for developers—but the proper fix for that isn’t to include some warning box saying “this feature, which isn’t meant for browsers anyway, isn’t implemented in browsers” like the W3C HTML fork does. The proper fix is outlined at in the WHATWG issue tracker; unfortunately, this is one of the 654 open issues that hasn’t yet been fixed in master. We’d welcome your help!)
It’s unfortunate that people are referring to this post as if it were revealing a deep difference between the W3C HTML fork and the WHATWG HTML Standard. Instead, it’s just based on a series of misunderstandings. If people are interested in some more fact-based accounts of the differences, see Anne’s blog post or compare the W3C fork GitHub activity with that of the WHATWG HTML Standard
Love Domenic Denicola correcting someone who has worked in web standards for a decade and has been around for the entirety of WHATWG and who is literally announcing that they’re working on the W3C spec and that this is how they view the difference. I feel like I need a new _____splaining word for that. Especially since there is a debate in that issue and, when I read it, it’s real clear that there are different perspectives in there, not a single “right” answer that’s already been identified.
Funny you should mention the outline algorithm. I’ve just been looking around at the various implementations and documentation of it that are all over the Web.
(Yes, there is a bunch of code. But no, it isn’t written by browser companies so isn’t an official part of a browser).