W3C Says Don't Use HTML5 Yet 205
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."
Re:W3C is the problem (Score:4, Informative)
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.
The bottleneck is mostly implementation, not standardization. For instance, Firefox 4 is going to be the first good implementation of HTML5 form enhancements, and those were first standardized in Web Forms 2.0 – in 2003. The spec hasn't changed all that much since then (although it has changed), and has been stable for years, but none of the major browsers gave it high enough priority to implement it well. Browser implementers have lots of things to do, like revamping UI and improving performance and security, and they can only implement so many standards per release. Then, of course, they report back all sorts of problems with the proposed standard, so it has to be changed, then changed again.
So it's mostly a matter of limited programming time, nothing mysterious.
Re:The final version is not due for several years (Score:3, Informative)
Who do you think is "working out" HTML5 now?
The fact of the matter is, a 1000 page technical document that precisely defines the behavior of an _existing_ complicated system takes a while to write. And that's before we start thinking about the time to implement (e.g. every browser having to rewrite its HTML parser, every browser having to modify its event loop, that sort of thing).
Re:More evidence of the W3C's increasing irrelevan (Score:5, Informative)
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 [whatwg.org] (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 [w3.org], 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 [infoworld.com].)
Re:Jeeze. (Score:4, Informative)
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 [w3.org] 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 [w3.org] 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.
Re:W3C is the problem (Score:3, Informative)
The bottleneck is mostly implementation, not standardization. For instance, Firefox 4 is going to be the first good implementation of HTML5 form enhancements, and those were first standardized in Web Forms 2.0 – in 2003. The spec hasn't changed all that much since then (although it has changed), and has been stable for years, but none of the major browsers gave it high enough priority to implement it well. Browser implementers have lots of things to do, like revamping UI and improving performance and security, and they can only implement so many standards per release. Then, of course, they report back all sorts of problems with the proposed standard, so it has to be changed, then changed again.
Correction -- Firefox 4 is going to be Firefox's first release that begins to support the HTML5 form enhancements. Opera has already supported those form enhancements since version 9.5 [opera.com].
Re:The final version is not due for several years (Score:3, Informative)
> I should infer that the writers of the HTML5 recommendation are creating the documentation
> to fit the existing browser implementations of HTML5?
Not quite.
There are two parts to HTML5. There's the "describe how the web works" part. This would be HTML parsing, the Window object, etc. This consists of reverse-engineering the existing browsers and then specifying something preferably sane that, if implemented, gives a working web browser that works with actual web sites.
The other part is the new features part. This consists of writing specifications of new features, fixing them based on implementor feedback, etc.
> What does time to implement have to do with the writing of the recommendation?
A W3C standards-track document doesn't become a Recommendation until there are two interoperable implementations. That means the spec text is written, a test suite is written, and two independent implementations are both passing the test suite.
> W3C writes the recommendation, and browser developers implement the recommendation in
> their software
Writing specs without implementor feedback is an excellent way to write specs that can't be implemented in practice (e.g. are self-contradictory, contradict existing de jure or de facto standards, require behavior that any sane application developer is unwilling to impose on his users, etc).
Lots of specs out there like that. They end up being implemented "incorrectly" (e.g. ignoring part of the self-contradictory text, and probably different parts in different implementations, ignoring the parts of the spec that don't work with other specs or with users), and then people bitch and moan about the buggy implementations. That's not really a world that we want all that much.
Sound advice (Score:3, Informative)
The usual games of trying to put facts on the ground first to "win" a standards battle....
HTML5 needs a LOT of work, especially in the realm of security.
Re:Flies in the Face of Common Sense Too (Score:5, Informative)
A little history about HTML5 books: For the longest time, people held off on publishing because of the same sort of FUD that W3C is spreading. What if it changes? What if I publish and a new feature becomes the hot topic and no one buys my book because I published too soon? But then Bruce Lawson and Remy Sharp published. Then I guess the other publishing houses realized that they'd better publish soon, or else Bruce and Remy were going to soak up all the disposable income that's been waiting on an actual book. So, like, one or two weeks later, Mark's book shipped. Then, like, 2 or 3 weeks later, Peter, Brian and Frank's book. So here's a big Thank You to Bruce and Remy for breaking the ice.
The cat's out of the bag, W3C. People are getting antsy to code. I don't you're going to get that cat back in the bag.
Re:More evidence of the W3C's increasing irrelevan (Score:5, Informative)
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.
This isn't the W3C. (Score:3, Informative)
...just a guy who happens to be part of the W3C [w3.org] stating his personal opinion. There is no official press release or publication on the W3C site itself--and, for that matter, not even any on this guy's personal web page or Twitter feed (when did he even say this?).
Re:The W3C needs a big reality check. (Score:3, Informative)
I can appreciate that some of that would seem more natural, but you can accomplish most (all?) of that using multiple classes and grouping. At the moment, I'd agree with this (http://dorward.me.uk/www/css/inheritance/) in that I'm not sure we even need OO style inheritance given that we have these other methods.
That said, if you REALLY need constants and inheritance you could implement some server side hackery. I realize that would not be optimal for most folks and breaks the independent style paradigm. :)
Re:More evidence of the W3C's increasing irrelevan (Score:3, Informative)
It sounds like he hasn't actually read the spec, or his comments are being taken out of context (sounds about right for InfoWorld). Different parts of it are at different levels of readiness, and this is indicated in the document itself. It also has a nice indicator of which browsers support which features.
You absolutely should not use HTML 5 now, nor expect it to be stable in the next couple of years. However, there is a large subset of HTML 5 that is stable, well supported, and ready for use now. Nothing is marked as stable in the HTML 5 spec until there are (at least) two independent implementations of it and people have had time to find problems with it. Using the stable bits is fine. Using the experimental bits is a recipe for disaster.
Re:More evidence of the W3C's increasing irrelevan (Score:3, Informative)
First off, Canvas is fucking redundant and never should have been created in the first place. SVG has existed since 2001. Canvas is a crappy JavaScript-only version of Canvas with half the features stripped out. There's no reason to use canvas in the first place - just use SVG. Most browsers support it and even if they don't there's good plugin support. And it's an actual released standard.
SVG is a declarative vector graphics format, while canvas is an immediate-mode 2D graphics API for JavaScript. Using SVG for a dynamic web application is kind of ridiculous – something as simple as ctx.fillRect(x, y, w, h) to draw a rectangle would require several lines of DOM methods.
HTML5 video is completely fucking useless, because:
1. You can't stream video. (No, not a file, I mean live video.)
You can stream live video just fine, if the format and browser supports it. I've heard reports of people getting this to work just fine with Ogg. This isn't the big use-case anyway, though.
2. You can't full screen HTML 5 video. (The spec forbids this as a security flaw.)
You can full-screen HTML5 video in Firefox 3.6 and later (IIRC) via the context menu. There's no standard JavaScript API to full-screen the video yet, because no one has worked out the security implications in enough detail yet: you'd have to design it carefully so that malicious scripts can't take over the screen (maybe just by copying what Flash does). WebKit has an experimental API in that regard. Plus, you can always just make the <video> tag fill the screen and let the user hit F11 if they want – YouTube does this, and it works pretty well (although it's not ideal).
3. There is no standard format, leaving you to encode an unknown number of versions. Hell, even if you stick with just H.264, you still need to encode to multiple profiles if you want to support everything.
HTML5 video is not yet usable as the only video format anyway, since you have to support IE
4. You can't seek in videos in anything remotely near a reliable manner. You know how you can link to a certain time in a Youtube video? Not possible in HTML5.
It's perfectly possible. YouTube has some JavaScript that will automatically seek the Flash video based on the fragment, and they could do exactly the same for HTML5 video. Seeking is as simple as setting video.currentTime [whatwg.org]. YouTube already uses this attribute to make its custom seek bar work.
5. You can't switch to lower/higher-bandwidth versions while the video is playing.
Of course you can. Just record currentTime, change the src, and then set the new currentTime. This is all trivial from JavaScript, much easier for a typical web developer than trying to communicate with Flash.
The HTML5 spec as is stands today is useless. The features it does offer above HTML4 already exist and are handled better via existing specs or plugins. Pretty much anything that isn't canvas or video isn't implemented anywhere, making the features entirely useless instead of done better elsewhere.
HTML5 is a vast spec that includes a huge number of improvements and refinements. The HTML5 parsing algorithm, for instance, will make a lot of weird websites work exactly the same across browsers when formerly they all behaved a bit differently – it's enabled by default in Firefox 4, and experimentally available for WebKit. This and many other clarifications are giving each new browser release more opportunity to be consistent with other browsers.
Canvas, video, and audio are not yet as reliable, widely available, or full-featured as their plugin-based equivalents, but they're suitable at least as fallbacks where the plugins aren't available (iOS, sometimes Linux). SVG and MathML embe