|
|
Subscribe / Log in / New account

WHATWG severs collaboration with W3C on HTML

By Nathan Willis
July 25, 2012

Fans of HTML will be either thrilled or annoyed by the news that there will soon be two independently maintained standards claiming to be the authoritative definition of HTML. The Web Hypertext Application Technology Working Group (WHATWG), a team comprised of representatives from various browser makers, announced that it is terminating its collaboration with the World Wide Web Consortium (W3C) on the standardization of HTML 5. In WHATWG's account of the split, it is continuing to develop the "living standard" of HTML, while W3C's HTML 5 specification is a frozen "snapshot" of HTML. Based on the public statements and history between the two groups, the underlying issue has more to do with the standardization process than it does with technical differences between their versions of HTML. Nevertheless, competition over who has the right to declare their vision of HTML the official standard will likely cause headaches for web developers.

WHATWG founder and chief public spokesman Ian Hickson posted the news to the WHATWG mailing list on July 19. Hickson (who is a Google employee) had been the primary editor for both the WHATWG and for W3C's HTML Working Group. According to the announcement, Hickson will continue to be the lead editor of WHATWG's HTML work, but leave the W3C editor position. WHATWG will formally be a W3C "community group" (CG), and will continue to use a W3C-hosted issue tracker. On the latter point, however, Hickson and the W3C did go through the existing bugs filed against the previously-unified HTML specification and clone separate copies, one for each of the now distinct specifications.

The upshot is that WHATWG now regards its version of HTML as the definitive standard, which will continue to evolve, without declaring numbered versions. Hickson concluded "My hope is that the net effect of all this will be that work on the HTML Living Standard will accelerate again, resuming the pace it had before we started working with the W3C working group."

Hickson cited two reasons for the split. First, the W3C separated out several parts of the HTML 5 specification into distinct sub-specifications (such as the 2D canvas element, postMessage, and server-sent events). The result, he said, was "an increasing confusion of versions" of the specification, in response to which WHATWG "went back to just having a single spec on the WHATWG side which contains everything I work on." Second is a divergence between the WHATWG and W3C processes. Attempting to explain what that means, Hickson described WHATWG's process as "fixing bugs as we find them, adding new features as they become necessary and viable, and generally tracking implementations." In contrast, he said, the W3C HTML working group is focused on "creating a snapshot developed according to the venerable W3C process."

What, work in a group?

To the untrained ear, those reasons might sound like WHATWG simply does not want to participate in a standards process at all. But there is more pointed criticism of the W3C on the WHATWG site, which calls the term HTML 5 a "buzzword" and enumerates several specific differences between the two standards, linking most of those to W3C HTML working group decisions that WHATWG evidently found disagreeable. The decisions that WHATWG critiques date back to mid-2010, although many of them seem to be connected to the working group's recent attempts to finalize HTML 5 over the course of 2011-2012 — such as disagreements over the actual wording of the specification and its inline advice (as opposed to, say, contradicting definitions of HTML elements or attributes).

WHATWG's disinterest in finalizing the standard was also evident in a blog post Hickson made in January 2011. That post announced that WHATWG's version of HTML would drop version numbers altogether, on the grounds that "the technology is not versioned and instead we just have a living document that defines the technology ." The HTML "Living Standard" terminology persists in the group's current communication. W3C, in contrast, is still moving forward with finalizing the HTML 5 specification and its successors. In an April message to the HTML Working Group list, Maciej Stachowiak said the W3C has begun to extend the HTML Working Group's charter to tackle "HTML.Next" and will proceed to examine proposals, including "the WHATWG HTML specification, which we anticipate will be one such proposal."

Viewed in that sense, the split between the two groups is not so much a forking of HTML into separate proposals as W3C's HTML 5 is a "frozen branch" of WHATWG's trunk. Or it would be, were it not for both groups' claims to represent the official standard for HTML. Hickson made this claim explicitly in his email, calling WHATWG's HTML Living Standard the "canonical description of HTML and related technologies". W3C's claim to ownership is less overt, but the group and its founder Tim Berners-Lee have written and formalized HTML since its inception in the 1990s. The first draft was written in 1993, with subsequent revisions published as IETF RFCs before the W3C process took over.

WHATWG was founded by a group of browser makers who felt that W3C's process was too slow and bureaucratic, so perhaps it is miraculous that the two groups were able to collaborate so successfully as long as they did. In any case, the practical question is what the split means for HTML developers — and, by extension, web users.

The great thing about standards is ...

The principal reason for concern is that if the two specifications drift in different directions, web developers could be forced to add even more workarounds to match both, or else sites could be branded "WHATWG HTML compatible" or "W3C HTML compatible," reminiscent of a return to the dark days of serious browser incompatibilities. In addition, WHATWG's "living standard" approach has its own critics, principally on the grounds that a constantly-in-flux document makes for a poor standard. A commenter named Mike asked on the 2011 blog post "How do you make a test suite and a browser compatibility chart for a “living standard”? It sounds like HTML is becoming a sort of Wikipedia revision style chaotic nightmare." Similarly, Jukka Korpela said:

“Living specification” sounds like a draft that may and will change at any moment and is probably not even complete at any moment of time but is still called a “specification”, since that sounds cool, technological, and impressive.

I can’t believe I feel the need to explain such a trivial thing, but really, a “specification” is a complete, consistent, stable, and published normative description. It can be cited and referred to as a requirement, e.g. in contracts and product descriptions. Typos, apparent mistakes etc. can and should be corrected, but the content is not changed as you go just because someone or some committee changes its mind. The specification definitely does not “live”; its life is in serving various purposes _as it is_. Development work takes place elsewhere and may eventually lead to a new specification.

So “living specification” is about as oxymoronic as you can get.

Indeed, the current presentation of WHATWG's incarnation of HTML does sport a Wikipedia-style "last updated" timestamp at the top (the last update was July 24, 2012 as of press time), plus floating tooltip-style markers that point out certain paragraphs as "ready for first implementations" from the margins — both features that hardly inspire confidence in the specification's stability.

Steve Faulkner replied to Hickson on the WHATWG list and took direct issue with WHATWG's assertion of canonical-ness. "The claim that HTML the living standard is canonical appears to imply that the requirements and advice contained within HTML the living standard is more correct than what is in the HTML5 specification." In particular, Faulkner pointed out that WHATWG's specification, like W3C's, cover only browser implementations and not authoring recommendations (which tackle critical issues like accessibility in addition to stylistic advice). On that front, Faulkner said, the W3C's specification has the "more accurate set of requirements and advice, that takes into account current implementation realities, thus providing [authors] with more practical advice and thus end users with a better experience."

Hickson and WHATWG have not responded publicly to Faulkner's message, but perhaps that is to be expected. It seems clear that WHATWG's primary motivation is continuing to add to HTML and related technologies as quickly and as often as its members wish. Of course, that highlights another thorny issue. As a standards-setting organization, WHATWG is not particularly accountable; membership is by invitation-only and Hickson can only be removed as HTML editor by the members. Other members of the public are welcome to join the mailing lists as "contributors," however. W3C may not be particularly democratic either, but its flavor of bureaucracy is more diffuse, with various working groups, interest groups, coordination groups, and boards.

The H postulated in 2011 that the seeds for the divergence of the two groups could be traced back to WHATWG's dislike of W3C's HTML 5 logo and related branding effort. One would hope that a core web technology like HTML would be above that level of triviality, but the alternative reasons given in public are not much more satisfying. With any luck, though, the web will eventually route around the damage — one way or another.



to post comments

WHATWG severs collaboration with W3C on HTML

Posted Jul 26, 2012 6:44 UTC (Thu) by Jandar (subscriber, #85683) [Link] (1 responses)

> "living standard" of HTML

This seems to me a try to bury HTML (in favor of apps ?).

WHATWG severs collaboration with W3C on HTML

Posted Jul 26, 2012 20:11 UTC (Thu) by drag (guest, #31333) [Link]

Html is as much a part of web apps as javascript or server side scripting is.

WHATWG severs collaboration with W3C on HTML

Posted Jul 26, 2012 6:53 UTC (Thu) by samth (guest, #1290) [Link] (1 responses)

Hixie responded to Faulkner here: http://lists.w3.org/Archives/Public/www-archive/2012Jul/0... with ensuing discussion.

WHATWG severs collaboration with W3C on HTML

Posted Jul 26, 2012 7:58 UTC (Thu) by przemoc (guest, #67594) [Link]

Much easier to follow version of the thread started by Faulkner's reply to Hickson on the WHATWG list.

http://thread.gmane.org/gmane.org.w3c.whatwg.discuss/36061

WHATWG severs collaboration with W3C on HTML

Posted Jul 26, 2012 7:49 UTC (Thu) by justincormack (subscriber, #70439) [Link]

I think it is better to see this as a reversion to what was going on before the W3C dropped its (failed) version and joined with Hixie. Culturally the two organizations are very different, but the W3C had to do something as its standard was dead. Now they have something they can standardize that is being used at least.

WHATWG severs collaboration with W3C on HTML

Posted Jul 26, 2012 11:58 UTC (Thu) by Velmont (guest, #46433) [Link] (2 responses)

There are a few misconceptions and errors around here. First read about passion from annevk (Opera):

<http://annevankesteren.nl/2012/07/passion>

Then about the storm in the teacup from mikesmith (W3C):

<https://plus.google.com/111991826926222544385/posts/QdGfr...>

WHATWG will follow what is actually implemented, so authors will not put "WHATWG HTML compatible" or the like for W3C version. If W3C version puts in some stuff, and it's implemented, it'll be copied into WHATWG version.

HTML is *not* something that can be versioned. It just doesn't work that way. Once something is in use on the web, you have to support it.

Also WHATWG was made because W3C abandoned HTML by working on XHTML 2. So it's not like

All in all, this is all very much overblown. We've worked like this for a long time, I'm in both HTML WG and WHATWG for Opera (speaking privately as usual though). And divergence is about what annevk said in his post, not about any HTML5 logo, that's crazy talk IMHO :-)

WHATWG severs collaboration with W3C on HTML

Posted Jul 27, 2012 7:54 UTC (Fri) by cmccabe (guest, #60281) [Link]

It seems to me like HTML never really gelled as a standard, probably because:

* The failure mode for HTML is "soft"-- a page renders wrong, but it's usually still readable. In contrast, if your C program compiled wrong or your NFS server could not talk to the client, it would be a hard failure. So people feel that it's not a big deal if HTML parsers disagree about a lot of things.

* It's pretty easy to change web pages. It's not like recalling half a million toasters because they don't meet electrical standards. You just change a line on your server, and you're done.

* Microsoft never wanted to implement many features. They dragged their feet on PNG support, SVG support, WebGL, a lot of CSS stuff, etc. Google and some other companies wanted to push the web application concept as far as it can go, and Microsoft wanted to prevent that as much as possible.

It seems like the HTML WG is indeed doomed to irrelevance. The WHATWG seems like it will at least serve as a discussion forum for browser developers, which is probably the best we can hope for. It still grates on me when I hear the phrase "living standard"-- it's a doubleplusungood misuse of the language.

WHATWG severs collaboration with W3C on HTML

Posted Jul 31, 2012 7:29 UTC (Tue) by dvdeug (guest, #10998) [Link]

I don't see HTML being terribly different then anything else in the versioning department. One HTML book I read had a 100 page chapter devoted to HTML features found in Netscape 4 ... and no other browser. Stuff that's out there can die.

What a version means is that I can have a program verify that my HTML is HTML 4 or HTML 5, that I can tell the web browsers my HTML gets sent to that and they know my HTML can be treated as such, and not with the kid gloves of HTML 3.2 that was only tested with Netscape. I can also write to a standard and anticipate whether or not an office that stabilized on an old web browser can read it, whether a tool that promises to speak HTML 5 can understand it. A version means that people and tools and systems can offer and expect certain things from each other.

Maybe it doesn't mean much to webbrowser writers. But there's people out there besides webbrowser writers, people who don't want to be on a never-pausing treadmill.

Seems both need to buy a clue

Posted Jul 26, 2012 19:21 UTC (Thu) by jmorris42 (guest, #2203) [Link] (5 responses)

Is there an actual HTML5 standard from either of them that you could point to and demand compliance to? It seems apparent that WHATWG doesn't even consider that a desirable thing so we can safely forget them, but just how much longer does W3C plan to dink around?

But even then, is there even one browser that is or will be 100% compliant to either spec at any moment in time? Unless there is it is again pointless. The whole idea of a standard is that one can take it, create content that adheres to it and expect it to display across a wide range of devices. Is that likely? Nope. So it means browser checks and constant tweaking forever and the only 'html5' apps likely to ever exist will be Metro on Win8 because at least it will be a reasonably stable target in wide deployment. Bah.

I need a clue too

Posted Jul 26, 2012 22:52 UTC (Thu) by man_ls (guest, #15091) [Link]

Specs have open ends and implementations have dark corners; it is hard to claim 100% compliance unless a standard is both very old and completely understood. I don't see the point in requesting 100% compliance at this stage.

Seems both need to buy a clue

Posted Jul 28, 2012 19:01 UTC (Sat) by Velmont (guest, #46433) [Link]

Not the whole spec, no, we keep adding stuff to it. Anyway, if the spec is bad and loose, it's easy to be 100% compliant, but that isn't really helping the web all that much. There are quite a few specs (or in the HTML case, parts of the spec) where we are all pretty much compliant.

Opera is very good in many parts, and not so very good in others :P

Anyway, the best way to get bug free specs is to continuously iterate, fix bugs and align with what the web needs.

Authors don't code to spec, so browsers and specs need to consider that

Posted Jul 28, 2012 19:20 UTC (Sat) by Velmont (guest, #46433) [Link] (2 responses)

If everyone would just code to the spec, and not do the horrendous browser checks (sniffing :( ) that you are referring to, the world would be a much better place. The problem is not that there are not good, stable and nice specs, it's that web authors never follow them. They write for one browser where they check what works and what doesn't.

Had they actually written after the spec text, then everything would've been better and easier to everyone. That's not how the web works, so it's impossible to have a wonderland system build on that.

Also, we don't break backwards compatibility. That was the whole reason Opera went together with Google and Apple back in the days to form the WHATWG. W3C wanted to boil the ocean and break everything with xhtml2.

We revert changes and edit specs all the time when we find that sites depend on it. It has to be that way out in the real world wild web.

Authors don't code to spec, so browsers and specs need to consider that

Posted Jul 29, 2012 11:41 UTC (Sun) by anselm (subscriber, #2796) [Link]

If everyone would just code to the spec, and not do the horrendous browser checks (sniffing :( ) that you are referring to, the world would be a much better place.

If I was supposed to standardise HTML, the first thing I'd standardise would be a simple, robust method by which a program could find out exactly which HTML features a browser supported and at what version level. This would do away with »horrendous browser checks« and make it possible to modularise the rest of the work. It would also make it possible to compare the HTML implementations of various browsers in a more straightforward manner, and make »coding to spec« a more viable proposition.

I'm actually quite surprised that this apparently isn't being done.

Authors don't code to spec, so browsers and specs need to consider that

Posted Jul 31, 2012 15:39 UTC (Tue) by nickbp (guest, #63605) [Link]

So, I think a strong "boil the ocean and break everything" specification that you mention would actually solve the "web authors don't follow the spec" problem that you mention.

If bad behavior is such a problem, then perhaps the next HTML specs and implementations shouldn't be so permissive of it. Likewise, it should be easy for both the web developer and browser developer to test and verify good behavior. Otherwise the problem will just continue to get worse as more features are piled on.

WHATWG severs collaboration with W3C on HTML

Posted Jul 26, 2012 22:38 UTC (Thu) by Baylink (guest, #755) [Link] (8 responses)

> The technology is not versioned

Yeah; cause that's working out so well for Firefox.

Why don't people understand why versions exist?

Anyone here tried to write any code in Python? Is it still running? How old is it? Do they still maintain the interpreter you run it on? Would you want that interpreter to be "continuously versioned"?

How many versions of C are there? 2? 3? and it's 40 years old. I believe there may be a moral here...

You can't version the web

Posted Jul 28, 2012 20:30 UTC (Sat) by Velmont (guest, #46433) [Link] (7 responses)

I don't know what you're trying to say. If you're saying "versions don't work on the web" then yay you, if not, then:

Versions don't work on the web because we *always* need to be backwards compatible anyway. As said in the WHATWG FAQ:

Browsers do not implement HTML+, HTML2, HTML3.2 HTML4, HTML4.01, etc, as separate versions. They all just have a single implementation that covers all these versions at once. That is what the WHATWG HTML specification defines: how to write a browser (or other implementation) that handles all previous versions of HTML, as well as all the latest features.

One of the main goals of the HTML specification and the WHATWG effort as a whole is to make it possible for archeologists hundreds of years from now to write a browser and view HTML content, regardless of when it was written. Making sure that we handle all documents is one of our most important goals. Not having versions does not preclude this; indeed it makes it significantly easier.

BTW, there's lots of good info in that FAQ.

Also, you should never check for a "version" of something and neither never ever do browser sniffing to serve it something broken. You should do feature detection, and check whether what you want to use is available, and if not, then do something less optimal, or even fail at that point.

You can't version the web

Posted Jul 28, 2012 22:13 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]

> Browsers do not implement HTML+, HTML2, HTML3.2 HTML4, HTML4.01, etc, as separate versions. They all just have a single implementation that covers all these versions at once.
Yeah, sure. Pay no attention to all these "if (is_html4.2)" statements inside the source code.

Browsers indeed usually have a single implementation of layout engine, because even a single implementation is overwhelmingly complex. Having several implementations would be impossible to maintain.

And they're getting even more complex. We now have CSS-based tables, flexible layouts and so on. Except that they all work like shit.

I maintain that it's impossible to create a moderately complex fully flexible layout using div+css without using either fixed pixel (em, percentage) sizes or JavaScript.

You can't version the web

Posted Jul 31, 2012 7:41 UTC (Tue) by dvdeug (guest, #10998) [Link]

If the world were only browser writers and people writing for the latest browser, that would be fine. In reality, there's all sorts of tools that don't get updated every other day, both filtering HTML and taking HTML as an input format.

You can't version the web

Posted Jul 31, 2012 15:00 UTC (Tue) by wookey (guest, #5501) [Link] (4 responses)

Are you telling me that the DOCTYPE declaration at the top of a page doesn't do anything? I thought the whole point was that a doc said what spec it was written to and the browser rendered it in that way. But then I got left behind shortly after HTML3.2 and have no clue how the web works any more - it seems awfully complicated and mostly written in javascript rather than HTML.

I'm deeply uncomfortable with the idea that there is no such thing as a fixed 'HTML 5 spec' you can write pages to. I'm also surprised tha said spec isn;t already finished - I thought people were using it already, but apprently that's all just 'pre-release' versions, with the concomittant issues when the final spec changes.

You can't version the web

Posted Aug 1, 2012 11:01 UTC (Wed) by cladisch (✭ supporter ✭, #50193) [Link] (3 responses)

In theory, a document with a DOCTYPE declaration claims to be valid HTML, but this doesn't help you in practice because there are too many pages out there that consist of the all-too-common tag soup and have the DOCTYPE anyway for purely cargo-cult reasons.
"Why do so many pages have a DOCTYPE?"
"Dunno."
"Let's add it too, just to be sure that the HTML gods do not get angry."

You can't version the web

Posted Aug 5, 2012 8:00 UTC (Sun) by dvdeug (guest, #10998) [Link] (2 responses)

Which is an easily solvable problem going ahead. If next time they introduce a DOCTYPE, have Microsoft, Mozilla, Google and Apple/webkit agree that it does not render if it's not valid. At that point, no web designer can simply slap a new DOCTYPE on old crap.

You can't version the web

Posted Aug 5, 2012 9:01 UTC (Sun) by johill (subscriber, #25196) [Link]

I don't think that's true. That would mean they also have to agree on all the little bugs in the rendering engines :-)

Otherwise, what will happen is that one browser has a bug and accepts something wrong, and then the others will be forced to also accept that because the fix won't be deployed quickly enough.

You can't version the web

Posted Aug 5, 2012 9:10 UTC (Sun) by cladisch (✭ supporter ✭, #50193) [Link]

Such pages would render in old browsers, so the first new browser release would break them. I cannot see any browser vendor agreeing to this.

WHATWG severs collaboration with W3C on HTML

Posted Jul 28, 2012 23:14 UTC (Sat) by skybrian (guest, #365) [Link]

This is sort of like a dictionary writer giving up on trying to "standardize" English and just documenting common use. It's descriptive, not prescriptive. The web changes and they just try to keep up.

What it also says is that a browser is never done, and if you don't have a dedicated team creating new versions, you're not going to keep up. The idea that you can specify software, build it, and then use it without changing it is nonviable when it comes to HTML in the wild.

That fits the web as it exists today, but I wonder whether it will slow down in a few years, when devices aren't changing much and browser vendors want to redeploy their browser teams to the new shiny.

Markup validation service

Posted Aug 2, 2012 22:21 UTC (Thu) by tjc (guest, #137) [Link] (1 responses)

Does WHATWG have—or plan to have—a markup validation service similar to W3Cs?

Markup validation service

Posted Aug 7, 2012 14:43 UTC (Tue) by pdundas (guest, #15203) [Link]

with a timestamp, presumably...
"this page was valid on xx/xx/xxxx (but the living spec may have moved)"


Copyright © 2012, Eklektix, Inc.
This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds