21 replies to this topic

[Boz]

The_Decryptor, on 22 July 2012 - 11:24, said:

I'm still not sure where you're getting the idea that the specifications are different, you keep referring to the W3C copy as the definitive version, which is wrong, the WHATWG version is the definitive version. If the W3C snapshot disagrees with the WHATWG version, then it's wrong. It's not separate (And if it is, then nobody would use it since the browser makers are following the WHATWG version, etc.)

From Ian Hickson himself:

Quote

A few years ago (around 2007), we started working with the W3C on what we
were then unofficially calling "HTML5", and officially calling "Web
Applications 1.0". We renamed the specification "HTML5", and the W3C began
publishing a copy of it as well. Not long after, the W3C side of this
effort decided to split their version of the spec into subspecs (e.g.
splitting out the 2D canvas API, server-sent events, postMessage, etc),
and for a while we tried to match that on the WHATWG side. The result was
an increasing confusion of versions of the spec, so we eventually went
back to just having a single spec on the WHATWG side which contains
everything I work on, which we now call the "HTML Living Standard". Over
the years, this document and the various documents on the W3C side have
slowly slightly forked, as documented at the top of the WHATWG spec.

More recently, the goals of the W3C and the WHATWG on the HTML front have
diverged a bit as well. The WHATWG effort is focused on developing the
canonical description of HTML and related technologies, meaning fixing
bugs as we find them [1], adding new features as they become necessary and
viable, and generally tracking implementations. The W3C effort, meanwhile,
is now focused on creating a snapshot developed according to the venerable
W3C process. This led to the chairs of the W3C HTML working group and
myself deciding to split the work into two, with a different person
responsible for editing the W3C HTML5, canvas, and microdata
specifications than is editing the WHATWG specification (me).

So no.. WHATWG is not "definitive" standard. It's not standard at all. It's introducing new features that will go far ahead of W3C HTML standard and will be implemented however browser makers feel they should (in their own way) and then they will try to patch things with W3C if the relationship doesn't collapse completely.

I don't see how any of this can be good. The one bright side was that WHATWG and W3C worked together and created one HTML standard that should have evolved in unified way. Obviously this didn't work out and now even bigger fragmentation between features will happen.

[Boz]

Majesticmerc, on 22 July 2012 - 11:29, said:

This story is getting blown out of proportion to be honest. No browser can be considered to be HTML5 compatible unless it implements the W3C spec. The point of the WHATWG spec is to get things done. The W3C spec process takes too long, HTML5 won't become a full recommendation until 2014, which means that it'll have taken 6 years from first draft to final recommendation. The WHATWG basically want to change the spec drafting mechanism so that things get done quicker. Something that is desperately needed.

Well that's the problem.. You will have 2 HTML "standards" that browser will implement. Things that WHATWG considers new features and W3C stuff. Eventually you will have a mess of browsers who support different features based on how they feel it benefits the company making a browser.

Needless to say this will be a mess for developers.

If you thought targeting just one HTML5 standard and dealing with compatibility across browsers, wait till you see how this will work out.

[winlonghorn]

Boz, on 22 July 2012 - 08:46, said:

http://techcrunch.co...d-not-standard/

http://www.theverge....fork-w3c-whatwg

It figures! HTML5 had great promise, but now they went and split it into two standards! As for WHATWG's version, I am all for constant additions and new technology, but a developer like myself cannot be confident in something if it is constantly evolving! That makes it awful hard to decide whether or not to implement features. *Sigh* Oh well, I guess I will go the route of implementing the new technologies where they make sense and falling back to older technologies for those that don't have browsers to support the features. Such is the life of a developer! lol

[+Majesticmerc]

Boz, on 22 July 2012 - 12:01, said:

Well that's the problem.. You will have 2 HTML "standards" that browser will implement. Things that WHATWG considers new features and W3C stuff. Eventually you will have a mess of browsers who support different features based on how they feel it benefits the company making a browser.

No, the W3C specs will be a snapshot of the WHATWG spec, therefore the W3C spec will be the same as the WHATWG spec, just older. Think of the WHATWG spec as the "bleeding edge" spec, and the W3C spec as the LTS spec. If something goes into the WHATWG spec, all the browsers will implement it. Anything where there is significant disagreement won't go into the spec until agreement is reached. The WHATWG specs will still be specifications. Any browsers not implementing the WHATWG spec won't be HTML n compliant, since the W3C spec will still require the feature be implemented in that manner.

Boz, on 22 July 2012 - 12:01, said:

Needless to say this will be a mess for developers.

If you thought targeting just one HTML5 standard and dealing with compatibility across browsers, wait till you see how this will work out.

I really don't think it will be. HTML5 is HTML5, it's a defined and unchanging W3C specification. Web developers looking to have a highly accessible and compliant spec should use the W3C specification. Anyone looking to try cutting edge features can use the WHATWG rolling spec, but need to be aware that the specification is subject to change, and they'll need to be prepared for that, but how is this any different from how HTML5 was introduced? We had years of "Your browser doesn't support HTML technologies such as <canvas>" already, what's going to change?

If anything, this will be good for the HTML spec progress, because it draws a distinct line between the W3C and WHATWG specs. HTML 5 was a constantly changing specification, and developers looking to use HTML5 tech had to deal with that. Now, HTML n developers will always be assured that the W3C specs will never change, but if they want to use bleeding edge stuff, they can use the WHATWG spec as a rough guide, knowing that this is a fluid spec that may introduce breaking changes between versions.

Any browser-specific "forks" of the specification will be implementation dependent, and aren't standardized to any extent, just as they always have been.

It's worth noting that this split between the consortia has been in place (as the article notes) since January of last year, and the world hasn't ended yet. The notable news here is that Hixie has quit as head of the W3C spec committee. This may pose communication issues between the consortia, however I don't see any significant issues.

[Athernar]

What a load of utter sensationalist nonsense.

Browsers will continue to implement the bleeding edge while being able to now have more solid specs to conform to that don't change constantly.

Of course the doomsayer in this thread would be a shill for a company attempting to lock down the web with their own proprietary cruft. Chrome truely is the new IE6.

Edit: The more I think about it the more awesome it sounds, if relevant DOCTYPEs are created for the new standards, this could be a great help in making sure sites don't break with rolling browser releases.

[The_Decryptor]

Athernar, on 22 July 2012 - 19:45, said:

...
Edit: The more I think about it the more awesome it sounds, if relevant DOCTYPEs are created for the new standards, this could be a great help in making sure sites don't break with rolling browser releases.

I think that would cause more issues (Look how many people use the XHTML Transitional doctype, that's just wrong), currently the DOCTYPE is only checked to see if the page should be rendered in quirks mode or standards mode, there's no different behaviour apart from that (Which is also why the WHATWG version of HTML is the definitive version, it details how to properly parse and handle all previous versions of HTML)

That's actually why the recommended doctype is "<!DOCTYPE html>", it's the smallest required doctype to trigger standards mode in browsers, and ensures your page won't fall out of standards mode in the future.

[Athernar]

The_Decryptor, on 22 July 2012 - 21:25, said:

I think that would cause more issues (Look how many people use the XHTML Transitional doctype, that's just wrong), currently the DOCTYPE is only checked to see if the page should be rendered in quirks mode or standards mode, there's no different behaviour apart from that (Which is also why the WHATWG version of HTML is the definitive version, it details how to properly parse and handle all previous versions of HTML)

That's actually why the recommended doctype is "<!DOCTYPE html>", it's the smallest required doctype to trigger standards mode in browsers, and ensures your page won't fall out of standards mode in the future.

I know how DOCTYPEs function, my point was more that if the two bodies are parting ways with the WHATWG becoming more proactive with their work, it would probably be useful to leverage the existance of the W3C's "after-the-fact" standards so there is a solid (unchanging) base for developers to work from. With the WHATWG's definitive but bleeding edge standard being "use-at-your-own-risk".