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."

Comments

So?

[The MAZZTer]

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.

Flies in the Face of Common Sense Too

[eldavojohn]

"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.

Re:Flies in the Face of Common Sense Too

[tixxit]

It is also a fantastic way to actually see what works. Essentially, we are seeing a big beta test of the HTML5 spec. No one is going to go out and build a HTML5 dependent web site, but lots of folks are building in enhancements for browsers with support. It helps ensure what makes it into the spec is what people are actually building sites with and what user's are actually using, rather than simply what the workgroup thinks people would like (or what is in their interests, for whatever reasons).

Re:Flies in the Face of Common Sense Too

[WebManWalking]

Mark Pilgrim's book is good. Very practical advice about how to use features. Also good (personal experience): Bruce Lawson and Remy Sharp, Introducing HTML5, and Peter Lubbers, Brian Albers and Frank Salim, Pro HTML5 Programming. Also good (Ben Nadel raves about it): Jeremy Keith, HTML5 for Web Designers. (I can't speak from personal experience about that one yet, but it was the first one on the iBookstore and I have the sample.)

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:Flies in the Face of Common Sense Too

[tyrione]

Your job is to write code, not to design a Sculpture to be admired throughout the ages. Designs are fluid, so is the code that implements them.

More evidence of the W3C's increasing irrelevance

[jaymz2k4]

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.

Who cares

[0racle]

Like anyone has ever listened to the w3c about standards and coding practices before.

Re:More evidence of the W3C's increasing irrelevan

[DJRumpy]

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.

Re:!surprising

[thestudio_bob]

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.

Re:More evidence of the W3C's increasing irrelevan

[Simetrical]

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.)

The W3C needs a big reality check.

[Lendrick]

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.

Re:More evidence of the W3C's increasing irrelevan

[Tridus]

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.

Re:Jeeze.

[Simetrical]

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.

Re:W3C is the problem

[Simetrical]

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.

I quite deliberately said that Firefox 4 will be the first good implementation of HTML5 form enhancements. I wrote HTML5 form support for MediaWiki, but disabled it – partly because of an inexcusably bad WebKit bug, but also because Opera's support is just cruddy. The UI is terrible – red-bordered boxes that only appear when you try to submit the form, not when you actually do the invalid input.

And I quickly found one killer bug: if a password element doesn't meet its constraints, it outputs the currently-entered password to the screen in plaintext, so <input type=password pattern=....> to require passwords of at least four characters is a non-starter. I reported the bug to Opera around the time 10.00 was beta, and it's still not fixed in 10.60. To replicate, cut and paste this into your URL bar:

data:text/html,<form><input name=foo type=password pattern=...><input type=submit></form>

Then type one or two letters in the password field (not more) and try to submit. So, Opera's great and all, but its implementation of this stinks.