W3C Says Don't Use HTML5 Yet
GMGruman writes "InfoWorld's Paul Krill reports that the W3C, the standards body behind the Web standards, is urging Web developers not to use the draft HTML5 standards on their websites. This flies in the face of HTML5 support and encouragement, especially for mobile devices, by Apple, Google, Microsoft, and others. The W3C says developers should avoid the draft HTML5 spec (the final version is not due for several years) because of interoperability issues across browsers."
I already had to test my websites across all the major browsers (especially IE8) before HTML5 to be sure that little differences weren't breaking everything. I would hardly expect HTML5 to magically change that anyway.
"The problem we're facing right now is there is already a lot of excitement for HTML5, but it's a little too early to deploy it because we're running into interoperability issues," including differences between video on devices ...
Well, I read an entire book on HTML5 and, as web developers have usually done, you just build in graceful fallbacks for unsupported browsers or devices. If APIs change, then they change but a lot of developers would probably rather opt for that than something a lot more proprietary and complicated. A whole chapter of the book I reviewed was devoted to extensively detailing how one would get video working in increasingly fallback ways depending on your preference of support. Why can't we keep up that mentality? The worst case is we just default back to the Flash/HTML4 route.
"HTML 5 is at various stages of implementation right now through the Web browsers. If you look at the various browsers, most of the aggressive implementations are in the beta versions,"
Another sage lesson from Mark Pilgrim's book: "Those who ship code win." You can sit there and tell everyone to 'hold on' all you want but if you don't give them a good reason to stop pushing forward with the implementation, they aren't going to wait for your consortium to debate for another five years. We're moving forward. There will be bumps. The time for discussing a completely perfect approach has passed and browsers will thrust what support they can into practice, warts and all. At some point this has to be done, it will never be truly perfect.
My work here is dung.
When the draft spec for a technology that moves so fast and has so much widespread adoption is still deemed several years off I don't know how anyone can take their recommendations seriously. We're already at a level of fairly good interoperability amongst the core browser engines for the base features we need. If developers and designers took any notice of this then we'd probably all be still building sites with tables.
jaymz
Like anyone has ever listened to the w3c about standards and coding practices before.
"I use a Mac because I'm just better than you are."
It seems obvious to me that you wouldn't use a technology that would work in less than half of the intended audience (unless you make it degrade gracefully).
But the real question is why does it take so long to come up with these standards? HTML5 started by WHATWG back in 2004. CSS3 has been around since 2005. Just get them finalized already. Don't whinge about browsers not fully supporting the standards if you don't give them a fixed document to work towards.
My thoughts exactly. This reminds me of 'Pre-N' wireless, which took far too long to ratify a standard that was already in wide use. They sat on their asses so long, it became a joke in the industry. If the governing body takes this long to certify it and they are claiming 'years' more in the future before the standard is finalized, then something is broken. This smacks of Google's 'beta' status. Eventually you have to shit and get off the pot.
Essentially they just need to finalize it, and for those bits that aren't production ready, defer them to HTML6.
I had to read that part a couple times to make sure it was right. Several years? What are these guys smoking? They actually expect people to wait that long?
So you would rather have everyone wait for them to "approve" it in 3-5 years, tell people to start using it and then find out that there's problems with real-world use. At which point they have to go back to "debating" how to fix the problems, which might takes another 3-5 years.
Unfortunately, you have to get people to start using it. Better to start finding out about "problems" now before the draft is finalized. As long as people are putting in "safe" fall-backs, then this really isn't a problem. I don't see it as extra work, since I was already having to do this for IE6 anyways.
I see you 2 and raise you another 2.
The real Sig captains the Northwestern. This one captains
Finalized standards are the leading cause of cold chairs. W3C and IEEE are doing their part to combat this injustice.
What we need is "a day in the life of a W3C draft" article to figure out why these standards and recommendations take so long to mature.
* chirp * chirp *
When the draft spec for a technology that moves so fast and has so much widespread adoption is still deemed several years off I don't know how anyone can take their recommendations seriously. We're already at a level of fairly good interoperability amongst the core browser engines for the base features we need. If developers and designers took any notice of this then we'd probably all be still building sites with tables.
This is why the WHATWG – the body that originally developed HTML5, and which still develops a version in parallel to the W3C – abandoned the idea of rating the stability of the spec as a whole. The WHATWG spec version (which is edited by the same person as the W3C spec, contains everything the W3C spec does plus more, and has useful JavaScript annotations like a feedback form) is perpetually labeled "Draft Standard", and per-section annotations in the margins tell you the implementation status of each feature.
The W3C Process, on the other hand, requires everything to proceed through the Candidate Recommendation stage, where it gets feature-frozen, and therefore becomes rapidly obsolete. It's quite backwards, but doesn't seem likely to change soon. So for sanity's sake, you can just ignore the W3C and follow the WHATWG instead.
(I really doubt that Philippe Le Hegaret actually said anything like what he was quoted as saying in TFA, though. It doesn't match what I've heard from him or the W3C before – no one seriously thinks authors shouldn't use widely-implemented things like canvas or video with suitable fallback. It sounds more like an anti-HTML5 smear piece. Paul Krill has apparently written other anti-HTML5 articles.)
MediaWiki developer, Total War Center sysadmin
It's probably the "need" for paper and in-vivo meetings.
If you didn't need them, standards would fly instead of committee members.
HTML5 uses no in-person meetings. The HTML Working Group charter at the W3C even says "This group primarily conducts its technical work on a Public mailing list". Everything is done through a combination of the mailing list and Bugzilla, with some IRC discussion thrown in on the side. There are teleconferences, but nothing important is done there, and the editor doesn't attend them – the decision policy requires that all requests for changes be made through Bugzilla and other web interfaces. There's also no paper involved anywhere.
Really, almost nothing at the W3C is in-person. People contribute from all over the world, both W3C members and non-members. In-person meetings are impractical. This is particularly true for HTML5 – the WHATWG version of the spec is really managed exactly like an open-source project with a benevolent dictator, not at all like a conventional spec.
The reason specs progress slowly is because it takes lots of programmer-hours to implement them correctly. Most of HTML5 is fully specced and just awaiting implementation. Programming is expensive work.
MediaWiki developer, Total War Center sysadmin
Web developer here.
First off, HTML 4 has plenty of browser interoperability issues. Just try to develop something that works on IE and any other browser.
Secondly, for the love of God and all that is holy, HTML is primarily a visual medium that people look at on a computer screen! Separating content (html) from presentation (CSS) was an excellent idea. Failing to allow vertical centering without dumbass CSS and javascript hacks is not. Seriously, what the hell?
Third, why can't CSS styles inherit other styles or use constants? You were *finally* going to add that into CSS, and then some jackass decided not to include it because it would make it more *complicated*. Do you know what's complicated? Having to change 40 instances of a color in a CSS file because I can't define a damn constant. This is exactly the kind of shit CSS was supposed to *solve*. Safari implemented this briefly and removed it because *they were afraid people would like it too much and usage would become widespread before there was a standard*. Add it to the standard! Right now, we have to use ridiculous workarounds like CSS compilers, which don't fit very well into a lot of modern CMSs.
Fourth, stop deliberating and start releasing official standards, otherwise Microsoft will just run off and do its own thing and we'll all be boned *again*. You're doing way more damage than you're preventing.
Finally, your failure to support as standards things (like the aforementioned CSS vertical centering) that people need to do in the real world on a regular basis just leads web developers to use non-standard code and bullshit like Flash, which circumvents your standard altogether.
End rant.
This.
The W3C is a running joke at this point. They didn't even want HTML 5 in the first place. Now they're telling people to shy away from it for a few YEARS?
I don't know what Internet these guys are on, but it's not the same one that the rest of us inhabit.
-- "So they told me that using the download page to download something was not something they anticipated." - Bill Gates
Why does it have to be implemented before it can become a finalized specification?
Because before it's implemented, it's just some words on a web page, and no one has actually tried it. Implementers inevitably spot parts that are vague, or too complicated or expensive or slow to implement, only when they actually try to implement it. Also, implementing it will mean it gets the regular security and UI review that all new browser features get, which will result in more feedback. And finally, you get almost no feedback from regular authors or users until it's shipping in at least beta versions of browsers. This is why no W3C spec can be declared finished without two interoperable implementations.
Another way of looking at it is that you could try speccing everything first, then implementing it. But it means that you miss a lot of things and wind up putting out a bad standard. Instead, web standards are usually developed in tandem with implementations, and are open to change as long as it's feasible if new information comes to light. They're only really set in stone when so much content depends on particular behavior that browsers can't change it without breaking websites – barring that, they can always be improved. Even Recommendations aren't final in practice, because they can be superseded by later versions. HTML 4.01 is a recommendation, but HTML5 contradicts it in many places, and takes precedence.
MediaWiki developer, Total War Center sysadmin