WHATWG severs collaboration with W3C on HTML
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:
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.
Posted Jul 26, 2012 6:44 UTC (Thu)
by Jandar (subscriber, #85683)
[Link] (1 responses)
This seems to me a try to bury HTML (in favor of apps ?).
Posted Jul 26, 2012 20:11 UTC (Thu)
by drag (guest, #31333)
[Link]
Posted Jul 26, 2012 6:53 UTC (Thu)
by samth (guest, #1290)
[Link] (1 responses)
Posted Jul 26, 2012 7:58 UTC (Thu)
by przemoc (guest, #67594)
[Link]
Posted Jul 26, 2012 7:49 UTC (Thu)
by justincormack (subscriber, #70439)
[Link]
Posted Jul 26, 2012 11:58 UTC (Thu)
by Velmont (guest, #46433)
[Link] (2 responses)
<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 :-)
Posted Jul 27, 2012 7:54 UTC (Fri)
by cmccabe (guest, #60281)
[Link]
* 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.
Posted Jul 31, 2012 7:29 UTC (Tue)
by dvdeug (guest, #10998)
[Link]
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.
Posted Jul 26, 2012 19:21 UTC (Thu)
by jmorris42 (guest, #2203)
[Link] (5 responses)
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.
Posted Jul 26, 2012 22:52 UTC (Thu)
by man_ls (guest, #15091)
[Link]
Posted Jul 28, 2012 19:01 UTC (Sat)
by Velmont (guest, #46433)
[Link]
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.
Posted Jul 28, 2012 19:20 UTC (Sat)
by Velmont (guest, #46433)
[Link] (2 responses)
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.
Posted Jul 29, 2012 11:41 UTC (Sun)
by anselm (subscriber, #2796)
[Link]
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.
Posted Jul 31, 2012 15:39 UTC (Tue)
by nickbp (guest, #63605)
[Link]
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.
Posted Jul 26, 2012 22:38 UTC (Thu)
by Baylink (guest, #755)
[Link] (8 responses)
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...
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.
Posted Jul 28, 2012 22:13 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link]
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.
Posted Jul 31, 2012 7:41 UTC (Tue)
by dvdeug (guest, #10998)
[Link]
Posted Jul 31, 2012 15:00 UTC (Tue)
by wookey (guest, #5501)
[Link] (4 responses)
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.
Posted Aug 1, 2012 11:01 UTC (Wed)
by cladisch (✭ supporter ✭, #50193)
[Link] (3 responses)
Posted Aug 5, 2012 8:00 UTC (Sun)
by dvdeug (guest, #10998)
[Link] (2 responses)
Posted Aug 5, 2012 9:01 UTC (Sun)
by johill (subscriber, #25196)
[Link]
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.
Posted Aug 5, 2012 9:10 UTC (Sun)
by cladisch (✭ supporter ✭, #50193)
[Link]
Posted Jul 28, 2012 23:14 UTC (Sat)
by skybrian (guest, #365)
[Link]
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.
Posted Aug 2, 2012 22:21 UTC (Thu)
by tjc (guest, #137)
[Link] (1 responses)
Posted Aug 7, 2012 14:43 UTC (Tue)
by pdundas (guest, #15203)
[Link]
WHATWG severs collaboration with W3C on HTML
WHATWG severs collaboration with W3C on HTML
WHATWG severs collaboration with W3C on HTML
WHATWG severs collaboration with W3C on HTML
WHATWG severs collaboration with W3C on HTML
WHATWG severs collaboration with W3C on HTML
WHATWG severs collaboration with W3C on HTML
WHATWG severs collaboration with W3C on HTML
Seems both need to buy a clue
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.
I need a clue too
Seems both need to buy a clue
Authors don't code to spec, so browsers and specs need to consider that
Authors don't code to spec, so browsers and specs need to consider that
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.
Authors don't code to spec, so browsers and specs need to consider that
WHATWG severs collaboration with W3C on HTML
You can't version the web
You can't version the web
Yeah, sure. Pay no attention to all these "if (is_html4.2)" statements inside the source code.
You can't version the web
You can't version the web
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.
You can't version the web
"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
You can't version the web
You can't version the web
WHATWG severs collaboration with W3C on HTML
Does WHATWG have—or plan to have—a markup validation service similar to W3Cs?
Markup validation service
Markup validation service
"this page was valid on xx/xx/xxxx (but the living spec may have moved)"