Spec editor talks standard splits and browser implementation. "It's mostly 'inside baseball' politics."
We recently reported on the WHATWG and W3C's relationship change, with spec editor Ian Hickson confirming he'd subsequently only edit the WHATWG spec. Those in the industry have been split on the decision and what it means for designers, developers, browser vendors and potential spec forks and fragmentation. Opera web evangelist Bruce Lawson argued that it "won't matter as this is what's been happening anyway", but author and web developer Shelley Powers was concerned. "It used to be HTML was a foundation on which we can build. Now, it's quicksand," she said.
We spoke to Hickson (IH) to get his take on the HTML5 'split' and to find out his opinion regarding potential fragmentation problems.
.net: Do you think the announced changes will make much difference to the industry, given that this is how things had largely been working for a while now?
IH: I doubt there'll be much difference. As you say, it's mostly how things have been working anyway. It's mostly 'inside baseball' politics.
.net: Could having separate editors be beneficial to HTML5?
IH: If by 'HTML5' you mean specifically the W3C snapshot, then yes, because it'll help the W3C HTML working group get the spec to REC, something which I was unable to do while also working on the HTML standard at the WHATWG. It's already a full-time job editing one spec, and having to do both would basically be like doing two full-time jobs!
.net: Could browsers using different versions of the spec as a 'baseline' cause fragmentation problems?
IH: That's not really how specs work in practice. The WHATWG spec's main driving force is to specify what browsers do. If the browsers started doing something different than what it said, then the spec would be updated to match what the browsers did, and so the result would be the same. This kind of thing happens all the time.
Similarly, the W3C spec is required by the W3C's own process to go through a phase of proving interoperability, which means testing everything in the spec and making sure at least two browsers support it, so they can't really diverge from the implementations either. These two constraints really should keep things in check.
.net: So do you see the two teams working together?
IH: Both groups as I understand it are still committed to fixing bugs found in the specifications, and I expect most of the time whichever spec gets edited to fix a problem last will just crib the fix from the other spec, so in practice it shouldn't be much of an issue. The specs should in theory remain mostly one a subset of the other.
.net: Does this mean you do not forsee any issues with spec forks?
I suppose there is the theoretical possibility that the W3C HTMLWG's spec will deviate from all this and ignore the process (it does sometimes happen that W3C groups are essentially allowed to opt out of certain aspects of the W3C process) but that's mostly up to the chairs and whoever they appoint as editor.
.net: Are there any other changes regarding the spec's future that our readers should be aware of?
IH: The spec I edit (at the WHATWG) is now called 'HTML' (fully, 'The HTML Living Standard'), not 'HTML5', to avoid confusion between the two specs.