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.

Re:So?

[Anonymous Coward]

Are you sure you're not thinking about CSS instead of HTML?

Re:So?

[mrops]

Same thing happening with 802.11n

ieee is stuck for so long that vendors have started pushing draft hardware. I can see why they are stuck, my dual mode router still works better on 802.11g compared to its 802.11n, n is choppy, slow and a huge hassels, particularly if u VPN. Clearly there are bumps with the n technology.

Re:So?

[Mazzie]

The argument in the article against using HTML5 due to interoperability issues with older browsers makes zero sense. No matter how much time passes, all of the new features of HTML5 will be broken in IE6 and the like. If on the other hand they are arguing that HTML5 breaks HTML4 features of IE6, then holy crap is the W3C incompetent. Am I missing something here? Other than that, the article reads like a Silverlight advertisement, so...

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

[Lennie]

"The worst case is we just default back to the Flash/HTML4 route."

Actually the worst would probably be silverlight ;-)

Re:Flies in the Face of Common Sense Too

[Anonymous Coward]

I don't see silverlight being worse than flash

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

[Anonymous Coward]

Agreed.

Turd == Shit

Re:Flies in the Face of Common Sense Too

[schlesinm]

"Those who ship code win."

If are standards group is going to wait years and years before finalizing a standard, then they have no reason to complain that people are going to start using it before you're ready.

Re:Flies in the Face of Common Sense Too

[atdt1991]

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.

Seriously, the pace of an individual company's innovation is not going to wait for a standards body that can't keep up.

If W3C wants to remain relevant, they'll have to pick up the pace.

Re:Flies in the Face of Common Sense Too

[ThatsNotPudding]

...will thrust what support they can into practice, warts and all.

The most compelling case for anti-virus I've heard for quite some time.

Re:Flies in the Face of Common Sense Too

[VGPowerlord]

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.

If APIs change, then you're stuck with a lose-lose situation.

Either
1. The browser makers have to support these non-standard (we could even say "proprietary") APIs, or
2. People who designed their sites for draft HTML5 and don't update them may partially work and fail in unexpected ways that the fallback doesn't cover.

We've already had a major electronics corporation telling people to use vendor extensions (specifically Apple with webkit extensions) instead of waiting for the finalized versions. We don't need HTML5 being diluted any further,

Re:Flies in the Face of Common Sense Too

[Anonymous Coward]

Please, everybody. Just take a breath and slow down. Take some holiday, say between now and Christmas and then enjoy the spring with a view to getting straight back into it by next summer. By then the standard will ccoked and you can just plug into the libraries we've been writing since you sat on your fat ass.

Re:Flies in the Face of Common Sense Too

[Anonymous Coward]

I agree completely - it's easy to whine about how html5 and its followers will take us back to the days of "this website is best viewed with [xxxxx] browser" but the truth is that if you use IE you're not in the real world and you just have to miss out on the next generation of the web.

If you use xp then you won't be able to get IE9 running and again, you will just have to miss out.

Truth is, I haven't tested one of the websites I've built for compatibility with IE for over 5 years. Though tbh I haven't been that busy with work.

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.

Re:Flies in the Face of Common Sense Too

[PietjeJantje]

I never get this. Organisation publishes a standard or programming language or whatever. Someone reads all the specs. Writes a book about it. Other people buy this book.

Why not go to w3c.org and read the specs?

Re:Flies in the Face of Common Sense Too

[WebManWalking]

If it were just someone who reads all the specs and writes a book about it, I would agree with you. But Remy Sharp and Mark Pilgrim are not just someones who have read all the specs. They actually know stuff.

Re:Flies in the Face of Common Sense Too

[PCM2]

Why not go to w3c.org and read the specs?

Reading the specs for a tennis racket, court, ball, and net does not teach you how to play tennis.

Re:Flies in the Face of Common Sense Too

[PietjeJantje]

If you need someone to hold your hand to learn HTML, you are in the wrong business.

Re:Flies in the Face of Common Sense Too

[lordmetroid]

Cause some people do not have internet I suppose.

Re:Flies in the Face of Common Sense Too

[PCM2]

If you need someone to hold your hand to learn HTML, you are in the wrong business.

Spoken like someone who's never built a cross-browser compatible Web site.

Re:Flies in the Face of Common Sense Too

[PietjeJantje]

Meh, argumentum ad hominem. In other words: game over.

Re:Flies in the Face of Common Sense Too

[the_womble]

No, the worst case is that we go back to ActiveX.

Re:Flies in the Face of Common Sense Too

[PCM2]

In other words: No argument in the first place. Seriously, go read the electrical codes for your state and then go build a house from scratch. You sound like a child.

Re:Flies in the Face of Common Sense Too

[PietjeJantje]

Excellent. You start trying to make me look bad because you lack an argument, reverse the argument, and continue with another ad hominem. Meh. Here's mine: Your excellent argument was to call an extremely experienced web developer an inexperienced child. So you are a complete idiot with no class whatsoever and you sound like a baby. I wish you good luck as a target for the publishing business for idiots. (These lame "books" are only written because lame idiots buy them, little boy, a well-known industry "secret")

Re:Flies in the Face of Common Sense Too

[Simetrical]

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.

That's all very well, but when browsers change widely-used APIs, they break sites. Then users complain loudly and refuse to upgrade, because the old version works better than the new one for them if they use those sites. So all the browser implementers except Microsoft refuse to change behavior in ways that will break sites more than absolutely necessary, and Microsoft only pulls off such behavior changes because of its compatibility modes. Which means that once the APIs are widely used, they don't change, period. Browsers will not break content.

Re:Flies in the Face of Common Sense Too

[Lucractius]

rather than simply what the workgroup thinks people would like (or what is in their interests, for whatever reasons).

From what I've seen... the workgroup doesn't know whats in their own interests, let alone what people would like.
This isn't a development process with code... this is a beurocratic standard development process.

Im just glad none of us have to wait for them to make up their mind. Were all just moving forward while they make up their mind.

Re:Flies in the Face of Common Sense Too

[aug24]

'-webkit-xxx' is already practically identical to '-moz-xxx' and as soon as W3C stop admiring their bellies, will simply become synonyms to... 'xxx'.

There is potential for a slight problem, sure. So the cost/benefit analysis is:

"Potential for a slight maintenance issue for the next two/three years" ...against...
"Lots of excellent features"

No brainer.

Justin.

Re:Flies in the Face of Common Sense Too

[VGPowerlord]

'-webkit-xxx' is already practically identical to '-moz-xxx' and as soon as W3C stop admiring their bellies, will simply become synonyms to... 'xxx'.

Except that, last I checked, Apple is telling people developing iPhone webapps to use -webkit-xxx, not xxx.

There is potential for a slight problem, sure. So the cost/benefit analysis is:

"Potential for a slight maintenance issue for the next two/three years" ...against...
"Lots of excellent features"

No brainer.

You're understating that problem. The problem isn't
"Potential for a slight maintenance issue for the next two/three years"
but instead "Doesn't work properly on non-webkit browsers"

You're right, it is a no brainer: Don't do it unless you want to go back to the bad old days where everything only worked on one browser (well... two browers, assuming Chrome supports it)... you're simply shifting which browser that is.

Re:Flies in the Face of Common Sense Too

[aug24]

As I said, WHEN W3C fix the standard in stone, -webkit-xxx and -moz-xxx will become xxx. So, no, neither Mozilla or Apple is advising to use xxx yet.

So you can have lots of lovely features to use in a way that will gracefully degrade (transitions simple don't occur, so fade-out becomes snap-out), and there's no problem worth speaking of. When the standards become standard, a very small change to the content of the css file will bring them in line.

And you're still going to need those graceful degradations because not everyone will upgrade on the same day anyway, so IE6 will still need support for a while.

In other words, we already support heterogeneous clients, so this is just business as usual.

!surprising

[iONiUM]

I don't really find this surprising in the least. I've been saying this for awhile now. Why would you possibly want to build a professional application on top of what is basically a mudslide? The maintainability alone is completely shot.

Not that I don't think HTML5 will have a huge impact in the future, it's just, I don't know why anyone would make a professional application in it *at the moment*. Better to stick with something that is mature and fully adopted.

Just my $0.02..

Re:!surprising

[NevarMore]

I don't really find this surprising in the least. I've been saying this for awhile now. Why would you possibly want to build a professional application on top of what is basically a mudslide?

The thing is thats how it is now and how it was before HTML5. People are still building websites and using them to make money so it can't be that bad.

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:!surprising

[bersl2]

I don't see why using HTML5 now is a problem, with two major provisos:

1. developers build-in the necessary hacks to deal with different implementations of the draft; and
2. developers maintain the site such that they upgrade to comply with updated drafts (if necessary) and the final standard.

Also, lol Slashdot for screwing up <ol> rendering?

Re:!surprising

[xaxa]

I'm writing a "small" (counting the number of templates required) web application at the moment. I've used HTML 5 elements, mostly for my amusement and learning.

The ones I've used are NAV, SECTION and HEADER (and I, in the HTML5 sense). I've also used a few new attributes, e.g. placeholder on a text INPUT field.

I might get rid of the NAV/SECTION/HEADER if I find any problems with IE6, but I think it's unlikely these bits of the spec will change.

Equally I've used some CSS3 stuff, e.g. to do row striping of tables, to fade in a drop-down box, and to highlight the target of a #link. I don't care if this breaks (although I think it's unlikely), but for the moment it's useful for Mozilla/Webkit/Opera users.

Re:!surprising

[Anonymous Coward]

Does your list need to be ordered, or is an unordered one more semantically correct?

Re:!surprising

[Hylandr]

I agree with iONiUM.

There is no clear advantage or improvement that HTML5 would provide in delivering information or selling goods to our customers on the web. I don't feel like dropping everything I am doing, to re-write or re-implement everything I have now, and the customer is perfectly fine accepting. NO Client ever cared what language the site is presented in, as long as it looks decent. Html 5 is grand I am sure, but I still present websites in php driven html 3. I have enough on my plate with the workload I have now.

- Dan.

Re:!surprising

[thePowerOfGrayskull]

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.

The nature of standards is such that they're not standards until they're approved and recognized. Flaws within the standards result in further standards and modifications - but at least you can then guarantee a minimum baseline of support. That also includes flaws -- if it fails, it will fail the same way across platforms.

Re:!surprising

[The Moof]

He's not saying don't use it. He's saying if you're building something for business purposes, don't spend the extra time and money to build an HTML5 version, build a series of workarounds for the various differences in HTML5 browsers, and the build a graceful fall back version for non-HTML5 devices. He's suggesting to use a spec that's matured.

You will still have the millions of other sites from hobbyists, pet projects, etc., out there who will use HTML5 and find its quirks and problems.

One more note from personal experience -

As long as people are putting in "safe" fall-backs, then this really isn't a problem

As someone who runs NoScript, I can safely say the people who put those "safe fall-backs" in are in the minority, and this is currently a problem, even without HTML5.

Re:!surprising

[paimin]

Not that I don't think HTML5 will have a huge impact in the future, it's just, I don't know why anyone would make a professional application in it *at the moment*. Better to stick with something that is mature and fully adopted.

You mean like (X)HTML4.x(strict|transitional), which is perfectly cohesive, and has identical and unchanging support across all modern browsers?

:-|

Re:!surprising

[SpaceLifeForm]

IE6 is a huge security hole, why are you even catering to the lusers that use it?

Re:!surprising

[xaxa]

We use it at work (although many people have semi-officially installed Firefox), on Windows 2000.

We want to upgrade, but the government basically cancelled all IT spending -- it doesn't seem to matter that we've hardly spent anything on IT for the last 10 years and desperately need to upgrade, or that we'd already agreed to purchase PCs (etc) from some companies before the new policy was announced. We've lost money from not buying the stuff we'd agreed to buy, and from wasting a lot of staff time preparing to upgrade.

</rant>

Re:!surprising

[Anonymous Coward]

So you would rather have everyone wait for them to "approve" it

Yes. Because until then, it's not a standard.

I don't see it as extra work, since I was already having to do this for IE6 anyways.

The IE6 situation is exactly the sort of shit that happens when you don't follow a standard. Everything goes sideways.

Play with it if you want. Test it, brutalize it. But until it's finalized, it's a moving target and not something to base production systems on.

Having said that, feel free to use it on your personal blog.

Re:!surprising

[bersl2]

Semantically, an unordered list would make more sense, but an ordered list fits my pattern of speech, so I chose to use it.

And funny, now it's rendering the numbers. Previously, it had displayed characters as if they were child posts folded up.

Re:!surprising

[Anonymous Coward]

Hence the ratification process and vendor specific extensions.

http://en.wikipedia.org/wiki/W3C_recommendation

http://www.css3.info/vendor-specific-extensions-to-css3/

thestudio_bob is correct.

Re:!surprising

[arose]

Flaws within the standards result in further standards and modifications - but at least you can then guarantee a minimum baseline of support.

Back in reality that is not how web standards work out. HTML4, CSS2 and PNG were finalized, did that mean that they were the minimum baseline?

Re:!surprising

[arose]

As someone who runs NoScript, I can safely say the people who put those "safe fall-backs" in are in the minority, and this is currently a problem, even without HTML5.

There is a big difference between having fallbacks for lacking features and fallbacks for existing features that the user deliberately disables. Having a duplicate version for all javascript (that can be quite a bit these days) in whatever the backend is a much bigger liability then a CSS hack for IE6. That said, it is true that far too few places do fallbacks were appropriate.

Re:!surprising

[Chuck Chunder]

Better to stick with something that is mature and fully adopted.

Ha ha, good one!

Re:!surprising

[The Moof]

If you design a site correctly and with that graceful degradation/fallback in mind, you don't need duplicate copies in your system. Developers should be building sites with the lowest common denominator in mind, then enhancing it with javascript/flash/whatever features. Far, far too many times do I pull up a page with nearly no content because they dev decided it's all loaded via ajax, or open a link in a new window only to see a url of "javascript:load(...);", or a page with all of the content absolutely positioned in the top left because all styles and layout are applied via javascript.

Those are the type of fallback problems I'm referring to.

Re:!surprising

[thePowerOfGrayskull]

You're combining two different issues. Naturally the existence of a standard doesn't force compliance.

The difference here is that all major players indicate willingness to be compliant with HTML5 - but can't do that 100% until it's official.

Re:!surprising

[the_womble]

If it gives you an excuse to stop supporting IE6 you might not end up with any more interoperability problems than you already had.

Re:!surprising

[Anonymous Coward]

Actually, you're combining a few different issues. Naturally there can't be a 100% official standard until it's bug-free and proven implementable.
The only way to do that is to implement the draft standard, use the draft standard in real world apps and adjust the draft accordingly. Once the issues are ironed out, the draft becomes recommendation.

Re:!surprising

[thePowerOfGrayskull]

Actually, you're combining a few different issues. Naturally there can't be a 100% official standard until it's bug-free and proven implementable.

Tell that to Microsoft and their officially standardized Office format ;) Seriously, wh

Re:!surprising

[Anonymous Coward]

Yeah, the officially standardized office format made by one vendor that only said vendor practically can be 100% compatible with.. Se the case against DIS29500. :P

Re:!surprising

[thePowerOfGrayskull]

Except it was later shown that even that vendor isn't compliant with the standard.

The point is that a standard can exist even if it's 100% unimplementable - as long as the standards body votes it that way.

Re:!surprising

[jc42]

I've been saying this for awhile now. Why would you possibly want to build a professional application on top of what is basically a mudslide?

That's a very good characterization of the Web from the start. Well, maybe it was internally consistent when there was only the Mosaic browser and a few academics using it. But as soon as the commercial folks got involved, it turned into a mudslide pretty much overnight. They took their usual approach, of learning just a little bit about the Web, then creating their products for their misunderstanding of it. Then they declared their misinterpretation "standard". The programmers either found ways to live with this unpleasant reality, or they found another job.

It'll be the same with HTML5. 10 or 15 years from now, we'll still be fighting all the incompatibilities in the (many more) Microsoft browsers. We'll still be learning all the niggling little incompatibilities in the "certified standard" browsers. We'll still be fighting bosses who insist that things work on their desktop system and nowhere else. And we'll have more obsolete browsers that we still have to develop before because there will be more millions of people out there who are still using them. And IE6 will still be a major browser.

(If you want to have some real fun with this, try developing a site that works well on the new "smart phones" that are coming out. And start thinking that 10 years from now, your boss will probably have one of them. ;-)

Re:!surprising

[jc42]

IE6 is a huge security hole, why are you even catering to the lusers that use it?

In my experience, this is usually necessary because it's what the boss (and/or most of top management) use on their desk. Of course, they have no idea what IE6 is; they just want it to look good "on the Internet", which of course is that window that pops up when they hit the "e" icon.

Given that level of understanding in the people who can fire you at any time, most people will at least try to make it not look too bad in IE6. The security holes are Someone Else's Problem, since you can't fix IE security holes yourself.

Re:!surprising

[Anonymous Coward]

Exactly. In which case it's a useless standard. :P

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:Who cares

[Anonymous Coward]

TFA sure doesn't.

Jeeze.

[allometry]

I don't understand why these things take so long? W3C and HTML5, IEEE and 802.11N... You think with this much "hype", these guys might get the HTML5 standard out the fucking door ASAP.

Re:Jeeze.

[denis-The-menace]

It's probably the "need" for paper and in-vivo meetings.

If you didn't need them, standards would fly instead of committee members.

Re:Jeeze.

[Anonymous Coward]

We need HTML5 because people aren't happy with HTML4. Let's not make the same mistake.

Re:Jeeze.

[Simetrical]

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.

Re:Jeeze.

[kccricket]

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.

Why does it have to be implemented before it can become a finalized specification?

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:Jeeze.

[TheRaven64]

A specification with no implementations has no bugs, right up until the first implementation. The WHAT WG has the same requirement as the IETF: two independent implementations. This ensure two things:

1. That it is possible to implement the spec.
2. That the spec does not contain anything specific to one implementation.

CSS was an example of failing the first test. It was inadequately specified, so implementations had to make guesses about what the spec really meant. This was later clarified, but by then there were incompatible implementations. ActiveX is an extreme example of the second problem - implementing ActiveX requires implementing the entire Win32 API in the browser, so is almost impossible for any browser on a non-Windows platform. Even if FireFox supported ActiveX on Windows, it would be delegating most of the implementation to the same libraries that IE uses, so would fail this test.

The W3C has a habit of releasing 'final' specifications with no implementations. This leads to things that are completely impossible to implement, or to spec-compilant but incompatible implementations.

No one ever expects the Spanish Inquisition

[Anonymous Coward]

Now that's an awesome idea. Maybe we should be more like the Inquisition and burn all the books. Yup. Impeding progress. Now that's the way to go.

IE fault

[gmuslera]

Not for not supporting HTML5, but for setting the precendent where a lot of developers made their site for the "de facto standard" of it. Implementing right now HTML5 is making the same kind of mistake, should not be future proof.

In the other hand, the main browser that have no clue on what HTML5 is is precisely IE, so now they are getting a bit of their own medicine.

Re:IE fault

[MBC1977]

Seems like I'm saying this a lot lately, lol; but I digress: How is Microsoft to blame again? A bunch of companies competed, Microsoft came out top (the method of which is irrelevant).

I've said it before, and it bears repeating: technical types need to consider that the general population does not give a shit about technical merits of a product or service. It just needs to do what they want it to do
(the particulars are irrelevant generally, but for a few who truly care about quality).

Re:IE fault

[TheRaven64]

Part of the point of HTML 5 is that it's possible to implement it using JavaScript and plugins. For example, the storage stuff can be implemented using Flash local storage. Canvas can be implemented using some JavaScript and WML. You actually don't need Microsoft's help to use HTML 5 with IE, you just have longer load times (and more potential security holes) for IE users because you need to pull in a load of third-party crap to implement it properly.

W3C is the problem

[Gadget_Guy]

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.

Re:W3C is the problem

[Simetrical]

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:W3C is the problem

[POWRSURG]

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.

Re:W3C is the problem

[Anonymous Coward]

Correction - Firefox is going to be the first browser with HTML5 form enhancements that anyone important cares about.

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.

Re:W3C is the problem

[DragonWriter]

But the real question is why does it take so long to come up with these standards?

Because it should. The problem is the idea that you shouldn't implement a standard until its done. The reverse is true: a standard shouldn't be done and frozen until, at a minimum, there exist independently-developed, interoperable implementations that acheive the purpose for which the standard was developed.

A "standard" that isn't implemented at all, doesn't have interoperable implementations, or which has interoperable implementations but doesn't meet the needs for which it was developed, isn't meaningfully done, and if its treated as "done" it will likely only ever be "done" in the sense of "dead" rather than "complete and worth using."

Re:W3C is the problem

[azrider]

>To replicate, cut and paste this into your URL bar:
>data:text/html,
>Then type one or two letters in the password field (not more) and try to submit.

Chrome 6.0.472.63 works
Opera 10.62-6438 fails
Firefox 3.6.10 fails

(All on Linux x86-64

Re:W3C is the problem

[Y-Crate]

Works properly on Safari 5.0.2

Re:W3C is the problem

[tyrione]

The starting point for Opera is 10.7 and Firefox is 4.x for HTML5 standard support.

Safari, Chrome, Epiphany and other WebKit browsers will all work. Let's test.

Chrome 7.0.536.2 dev: passes
WebKitGTK+ 1.3.4 passes
Safari Release 5.0.2 passes.

Why do they all now work? They work now with the HTML5 Algorithm complete. Go to html5test.com and check against Chrome's latest browser, WebKit Nightly and Epiphany Nightly or Epiphany with WebKitGTK 1.3.4.

Re:W3C is the problem

[Anonymous Coward]

The spec hasn't changed all that much since then (although it has changed)

It seems that recently there has been a change on the set of methods that are supported by an HTML5 form, where PUT and DELETE are no longer supported.

Big Mistake.

Re:W3C is the problem

[Simetrical]

>To replicate, cut and paste this into your URL bar: >data:text/html, >Then type one or two letters in the password field (not more) and try to submit.

Chrome 6.0.472.63 works Opera 10.62-6438 fails Firefox 3.6.10 fails

(All on Linux x86-64

You're not getting what's I was testing. Opera prints the password in cleartext when you do what I described, no other browser does. Firefox 4 nightlies print an unhelpful error message (unhelpful because I provided no title attribute on the input element, for brevity, otherwise it would be helpful), and everything else just submits the form, but nothing else prints the password.

Re:W3C is the problem

[Simetrical]

The spec hasn't changed all that much since then (although it has changed)

It seems that recently there has been a change on the set of methods that are supported by an HTML5 form, where PUT and DELETE are no longer supported.

Big Mistake.

There have been tons of minor changes like that, sure. HTML5 initially mandated PUT and DELETE be supported on HTML5 forms, which HTML4 didn't allow, but implementers are not likely to spend time on it without clear advantages that accrue to the average user or web author. You can still do PUT and DELETE from HTML via XMLHttpRequest, in clients that support script (the overwhelming majority), so it's not like it's a huge loss.

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:More evidence of the W3C's increasing irrelevan

[M. Baranczak]

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?

Adobe

[tomkinsightful]

Adobe will love this. Apple will hate it since they dont want to support Flash

Jorbs.

[ajlitt]

Finalized standards are the leading cause of cold chairs. W3C and IEEE are doing their part to combat this injustice.

Why not divide it?

[Rhaban]

If they can't write specs in less than several years, why not divide html 5 into its core components and concentrate the work on one piece at a time?

They could work on the final specs for the canva element first, then the video tag, client storage, and so on until everything is done.

There could be some kind of a transitionnal html5, falling back to html4 when something is not yet specified.

Re:Why not divide it?

[Anonymous Coward]

Even better, why hot just have "Current HTML" and update individual elements 4 times a year? There is basically no interdependence between different elements. Just update the elements one at a time. Major structural changes will require more time, but as long as we have element syntax and structure, who cares about a single, monumental, obsolescence-inducing update? That is hot a good plan and it is working as well as expected.

Re:Why not divide it?

[Simetrical]

If they can't write specs in less than several years, why not divide html 5 into its core components and concentrate the work on one piece at a time?

Because the spec is written. Go read it yourself. The editor cut back on adding new features a few years ago when it was clear that his feature-writing was outstripping implementers' ability to implement the features. He routinely replies to requests for significant new features by saying he's waiting for browsers to implement what's in the spec now before he adds more. The editing right now is almost all just that, editing – hammering out minor flaws that people discover and report. (There are some exceptions, like WebSRT.)

Re:More evidence of the W3C's increasing irrelevan

[kccricket]

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.

HTML5 is ready to use...

[Anonymous Coward]

...when FireFox4 isn't beta anymore.

I won't wait "several years" for WebM. Fuck you w3c!

The final version is not due for several years

[MorpheousMarty]

the final version is not due for several years

They can't ratify a new speck for YEARS? That's just not good enough. I know it's an important standard, but in 2 years they need to be finalizing HTML6. The web moves fast. If they want to take this long to move things forward, I'm all in favor of Google, Apple and Firefox working out the standards themselves. HTML should update twice yearly, just like Ubuntu.

Re:The final version is not due for several years

[BZ]

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:The final version is not due for several years

[MorpheousMarty]

Alright, it seems I spoke way too fast. I did some research on HTML (checked wikipedia) and it seems that updating HTML twice a year would be reckless. However, HTML4 was published as a W3C recommendation in 1997. Just to put that in perspective Windows98 and Napster were yet to happen. This is what AOL.com looked like at the time.

I respect what we've been able to achieve on this platform, but I can't help but feel it is holding us back as well.

Re:The final version is not due for several years

[kccricket]

I'm afraid I don't understand what your point is. Do you mean "working out" as in exercising or as in working out the details?

By what you're saying, I should infer that the writers of the HTML5 recommendation are creating the documentation to fit the existing browser implementations of HTML5? What does time to implement have to do with the writing of the recommendation? W3C writes the recommendation, and browser developers implement the recommendation in their software--that's how it (should) works.

Re:The final version is not due for several years

[BZ]

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

Re:The final version is not due for several years

[Lennie]

I think he/she means, HTML5 actually specifies everything HTML4 did, but with the bits which were not in HTML4. There was a lot of behavior in browsers which was not defined by any standard, HTML5 now includes all that. So to make sure everyone knows how HTML should work.

Re:The final version is not due for several years

[tixxit]

Releasing a new spec every 6 months sounds great. However, many web developers are still supporting the nearly-decade-old IE6! Keeping a site consistent (and working) across all browsers, right now, with just HTML 4 is incredibly time-consuming. Can you imagine if we had to support 20 different versions of a spec, just to ensure it works in every possible incantation of browser!

I'm all in favor of Google, Apple and Firefox working out the standards themselves. HTML should update twice yearly, just like Ubuntu.

Who do you think the committee is made up of?

Re:The final version is not due for several years

[MorpheousMarty]

I'm all in favor of Google, Apple and Firefox working out the standards themselves. HTML should update twice yearly, just like Ubuntu.

Who do you think the committee is made up of?

Well that is just bizzar, they are adding public support for features they are publicly (through this committee) asking developers not to use.

Re:The final version is not due for several years

[Arancaytar]

Standards are not like software.

Re:The final version is not due for several years

[Y-Crate]

Yes, I understand it's a challenging technical issue, but things like OS X (which is an amalgam of quite a few disparate technologies and APIs) took less time.

Re:The final version is not due for several years

[TheRaven64]

OS X is a linear descendent of NeXTSTEP, which first shipped in 1988. OS X 10.0 came with a rewritten WindowServer a port of the Carbon APIs (not a good one - they used different run loops and so on, and couldn't be mixed with the OpenStep / Cocoa APIs at the UI level), and an MacOS emulator. Even then, it took two years between the first Rhapsody Developer Preview (which didn't include the Aqua look, but did include most of the low-level stuff) and OS X 10.0, and prior to that it took two years between OPENSTEP 3.3 and Rhapsody. It was almost five years from NeXTSTEP 3.3 to OS X 10.0.

Re:The final version is not due for several years

[BZ]

OS X doesn't involve reconciling multiple constituencies or implementors with divergent interests. It was also not aiming to create a _specification_; just an implementation. It's often easier to implement than to specify.

Re:The final version is not due for several years

[Simetrical]

Alright, it seems I spoke way too fast. I did some research on HTML (checked wikipedia) and it seems that updating HTML twice a year would be reckless. However, HTML4 was published as a W3C recommendation in 1997. Just to put that in perspective Windows98 and Napster were yet to happen. This is what AOL.com looked like at the time. I respect what we've been able to achieve on this platform, but I can't help but feel it is holding us back as well.

The reason for this is because the W3C got derailed by XHTML. Work was focused for years on impractical specs that browsers didn't want to implement, like XHTML 2 and XForms. HTML5 only started in about 2004, so that's about seven years of zero new standardized HTML features. If you look at it that way, we've seen pretty decent progress in the last few years. Most of the delay is is the implementation, not the actual standards-writing. The HTML5 editor is avoiding large additions while he waits for implementations of what's already specced – you don't have implementers twiddling their thumbs because they have no standards to implement.

I guess you can say...

[Anonymous Coward]

the W3C doesn't like HTML... 5!

WTF?

[Anonymous Coward]

Do these guys live on some other planet? These are technologies that people need NOW. Browsers are already implementing them. By saying that it won't be ready for 5 years is ridiculous. By the time that the standard is published, it won't be the standard that people use. W3C needs to get off their ass and see what is happening on the web TODAY, and set the standard for TOMORROW.

Re:WTF?

[Ustice]

Do these guys live on some other planet? These are technologies that people need NOW. Browsers are already implementing them. By saying that it won't be ready for 5 years is ridiculous. By the time that the standard is published, it won't be the standard that people use. W3C needs to get off their ass and see what is happening on the web TODAY, and set the standard for TOMORROW.

oops forgot to sign in.

Re:More evidence of the W3C's increasing irrelevan

[Joehonkie]

Thank you. 802.11n vs. 'Draft-N' was exactly what came to mind. If we wait around for standards bodies to approve already functional and complete specs instead of moving on with our lives, technology will progress as slowly as an involuntary bureaucracy would have made it. It's the right thing to choose to move ahead with a complete and functional spec if the paper for it isn't being pushed fast enough.

Job postings

[Anonymous Coward]

I recently noticed job posting where the requirements included years of HTML5 experience. It's pretty odd reading that the W3C doesn't even want it used.

Re:Job postings

[Anonymous Coward]

I recently noticed job posting where the requirements included years of HTML5 experience. It's pretty odd reading that the W3C doesn't even want it used.

They also wanted the applicant to have 10 years of experience in Quantum Computing applications.

Awww crap

[l0ungeb0y]

Guess I'll have to tell my client that we have to stop work on their snazzy HTML5/AJAX site and hold off on it for a few years.
Ohhh wait.... the W3C is a bunch of prudish pencil-necks who move at a snails pace and are generally clueless to how the real world works.

Hey W3C: Bite me, developers will develop no matter what you say.

So if we wait until the W3C says it's OK

[revlayle]

It'll be the year 2525 or something....

Re:So if we wait until the W3C says it's OK

[Anonymous Coward]

In the year 2525, if HTML is still alive...

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

Slow w3c as usual...

[Yaa 101]

Maybe it's time they speed up their process a little?
Hopefully then they wont be passed by reality which develops at a much faster pace.
And then maybe they can avoid painful hiccups like XHTML 1, 1.5 and 2?

They started off great but more and more they are a waste of money and resources.

Re:Slow w3c as usual...

[Lennie]

Actually HTML5 would not have existed if we let W3C figure it all out by themselves.

It was actually the WHATWG which started on HTML5, W3C only has XHTML2 as a plan, but it wasn't even backwards compatible with XHTML.

The WHATWG has really done a lot to get HTML5 'out there' fast.

I think the people who do the work on HTML5 probably also need to work on CSS3. And it's a lot of work, so it seems.

What have we learned today?

[Zarf]

Don't use new technologies. Ignore HTML5.

Tried to deploy html5 embedded videos, failed

[Rashkae]

I tried to create a website that had to present some 480p videos. I encoded them to Ogg Theora, and figured I could forgo Internet explorer compatibility by encouraging visitors to use either Firefox or Chrome. Unfortunately, for all the noise Firefox makes about supporting open standard, their insistence on implementing their own video support rather than relying on Underlying os ability is completely messed up. Every platform I tested on exposed different bugs in Firefox that prevented the site from working. On Windows, some of the videos would freeze on first frame. On Ubuntu Karmic version of firefox, (3.5) the videos played well, but was unable to control position, (no forward or backwards seeking, even when buffering was full.). On Ubuntu Lucid, the videos would stutter and even while paused, made Firefox slow to respond to window scrolling. In the end, if I wanted to use HTML5 video, the only browser currently working well is Google Chrome. If I instead decided to use the de-facto x264 standard, I increase my browser compatibility across the board (except for Firefox.)... So yes, while I know video is only a small part of the changes, using the new specs is far premature.

Re:Tried to deploy html5 embedded videos, failed

[Lennie]

That version of Firefox was the first to support Ogg Theora, the streaming in particular isn't very good. Firefox 4 will be a lot better in that regard.

Re:Tried to deploy html5 embedded videos, failed

[markjhood2003]

I can corroborate this from the client perspective -- I have never seen an embedded HTML5 video actually run in Firefox 3.5 or 3.6 on either Windows, Linux or OSX no matter how many websites I've tried. When Mozilla first announced support for the html5 video tag I was surprised that none of the videos they presented as examples worked either. WTF?

Re:Tried to deploy html5 embedded videos, failed

[tepples]

If I instead decided to use the de-facto x264 standard, I increase my browser compatibility across the board

But how much would it cost to either A. obtain a license from MPEG LA to encode your videos using x264, or B. emigrate from the United States? According to a summary of the license terms, the royalty for H.264 use over the Internet is zero until the end of 2016, then $2,500 per copy (the free TV rate) afterward.

Re:Tried to deploy html5 embedded videos, failed

[shutdown -p now]

MPEG LA has already stated that they will further extend the existing no-fee provisions. So, practically, he will most likely not have to pay.

This is Great News!!!

[airfoobar]

If developers are encouraged to use HTML5 in its present form, which has inconsistencies across browsers, some websites will not work properly on some brand new, modern browsers -- not necessarily because the browsers are not standards compliant, but because the websites had to choose to be compliant with the unfinished standard implemented within a particular browser.

While most developers would normally choose the common factor and make their websites work on all browsers, other interests may prevent them from doing so. We've already seen Microsoft pay off certain popular websites to make their pages use HTML5 that only IE9 supports, as a marketing technique to make others look bad. While you could argue that all marketing is fair game (lies and subterfuge; smoke and mirrors), this sort of thing makes the job of the standards authority much more difficult, because some things may become defacto standards, thus undermining their efforts and ultimately making compatibility across browsers more difficult.

Remember the last time this sort of thing happened? Don't forget that Microsoft still has a good chunk of market share, and could invent new ways of making history repeat itself.

IE9

[Anonymous Coward]

The IE9 beta has at least some support for HTML5. I've learned over the years that if Internet Explorer implements a feature, every other browser of note has implemented it as well at least a few months beforehand. If that holds true for HTML5, then I don't see why we can't start using it right now.

Not that W3C approval is really necessary. I mean, people are going to use it when browsers support it, whether it's "approved" or not.

Keep up

[LinuxAndLube]

I also have a message, for the W3C: FUCK YOU

If they cannot keep up with the real world (and they cannot, as proven time after time after time), then that's their problem.

Addressing the problems of yesteryear.

[archen]

Is there any reason they couldn't just implement version numbers as they gain better support and address functionality? HTML 4 was intended to reign browsers in that had gone in all directions, to a standard implementation. Now I'll be back to checking what the big 3 browsers have in common so I can start using new features. Congratulations to W3C in managing to marginalize their relevance, yet again.

Years?

[Anonymous Coward]

Why the hell does it take *years* to "approve" this? Maybe we should have a new "standards body".

Re:More evidence of the W3C's increasing irrelevan

[xaxa]

In a work placement year I did the major electronics company had a couple of staff on the board for a standard -- it involved lots of XML and internet stuff, so it's not far from the kind of thing W3C does.

What took so long was working out whether technology that required infringing on each company's software patents should be "required" or "optional". In the end, Sony, Philips, Panasonic etc decided to pool their patents (their stuff is "required"), the patent troll companies were excluded by the big company's votes (so the neat technology they'd patented was "optional" or left out entirely) and the couple of small businesses or individuals who'd already got products running using the draft spec were ignored.

Re:More evidence of the W3C's increasing irrelevan

[Anonymous Coward]

no one seriously thinks authors shouldn't use widely-implemented things like canvas or video with suitable fallback

Um, I do.

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.

HTML5 video is completely fucking useless, because:

1. You can't stream video. (No, not a file, I mean live video.)
2. You can't full screen HTML 5 video. (The spec forbids this as a security flaw.)
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.
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.
5. You can't switch to lower/higher-bandwidth versions while the video is playing. This makes HTML5 useless for mobile devices - to the point where Apple uses proprietary QuickTime features to enable web video on the iPhone.

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.

So, yeah, I'd agree: wait for HTML5 to mature some. Right now it's useless.

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:The W3C needs a big reality check.

[atfrase]

What do you suppose are the chances that Microsoft itself is slowing down the W3C's progress, for exactly the reason you state? It would not be the first time a company sabotaged a cooperative effort to further their own interests.

Re:The W3C needs a big reality check.

[nametaken]

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:The W3C needs a big reality check.

[John Hasler]

> ...Microsoft will just run off and do its own thing...

With a market share below 50% and shrinking?

Re:The W3C needs a big reality check.

[Blakey Rat]

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.

My biggest gripe is lack of math. You can't add up static measures, like pixels, with user agent-defined measures, like ems. There's no way to say, in CSS, make this border 5 pixels + 10 ems. Huge oversight... what were they thinking?

Re:The W3C needs a big reality check.

[A Friendly Troll]

Third, why can't CSS styles inherit other styles or use constants?

This.

A million times this.

Why can't CSS natively do the following?

$constant_1 = 20em;
$constant_2 = 10em;

#container [ {
        width: $constant_1;
        min-height: $constant_2;
    } .foo {
        width: $constant_1 - 2em;
    }
]

instead of

#container {
    width: 20em;
    min-height: 10em;
}

#container .foo {
    width: 18em;
}

When I do CSS, I use a crapton of tabs to indent declarations, and I also get overly verbose in selectors to help with readability and maintainability. Like this:

#container .foo span.bar a

Some people would just write .bar a

But that doesn't tell me that much when I glance at the code...

Seriously, why can't we have nesting? We could even have smart CSS editors with block collapsing and expanding... And that would help a LOT.

#container [ {
    } .foo [ {
        }
        span.bar [ {
            }
            a {
            }
        ]
    ]
]

Some inheritance would also be sweet... But then again, we can already use multiple classes. Not that I like that approach very much.

Hm, Slashdot Preview doesn't show this properly... ".foo" should be on new lines. Maybe the posted comment will look better.

Re:The W3C needs a big reality check.

[SpaceLifeForm]

I would bet on it. Look what Microsoft did with OOXML to damage ISO

Re:The W3C needs a big reality check.

[Anonymous Coward]

I haven't had that much problems with colors. It might be because I parted the color definitions from the position definitions and use colors mainly to hint at the page structure. Either my elements inherit color from the parent or have a color depending on parent, grandparent or neighboring elements (>, * or some pseudo-element). In the rare case I need an override I specify a second class with the name of the color.

Re:The W3C needs a big reality check.

[Cidolfas]

Because that's an engineering solution in a medium populated with designers.

Also, I personally think you've found a solution in search of a problem, since good class naming practices essentially create a nest anyways (though not declaratory).

Re:The W3C needs a big reality check.

[phantomfive]

Wow. You succinctly described in three paragraphs everything I hate about CSS and HTML. If those problems were fixed, I would love web programming.

Re:The W3C needs a big reality check.

[chris.alex.thomas]

I'm a web developer too, give this man a cigar, a whiskey, membership of the club, whatever it takes, I couldn't have said it better myself. web development is a no mans land of grief, crap solutions and hacks, the only web pages that don't need hacks, are boring web pages like that loonatic Jakob Nielsen's website (which I refuse to put the url, in case he sees it as a good thing people like it). usability consultant my ass....

Re:The W3C needs a big reality check.

[Anonymous Coward]

Another web developer here, been doing it since 1995.

This why I still use tables for page layout. Don't get up in my grill that it's wrong. It WORKS. It worked 15 years ago and it still works now. In fact it works even better now because the rendering slowdown from nested tables has largely been solved with better bandwidth and processor speed.

When y'all get serious about CSS, I'll consider using more of it. But for now, you simply get in my way. Table layouts still rule.

Re:The W3C needs a big reality check.

[Homburg]

We should be able to do this in CSS 3, at last.

Re:The W3C needs a big reality check.

[dkf]

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.

It doesn't really. If the style coming over the wire isn't the style as written by the original developer, but has a collection of transformations applied to it in between (e.g., converting "constants" to their values) then who cares except the developer? What's really wrong is that CSS isn't done with a syntax that can be produced from XSLT processing easily; if it was, all this whining about a lack of programming flexibility would be seen for what it is.

Re:The W3C needs a big reality check.

[A Friendly Troll]

The point is that true nesting would allow code collapsing, which would be just awesome. Yeah, it's engineer-y, but it would be very practical for everyone. Constants, too, when you're dealing with clients who want everything by the pixel (ugh...) and then tell you to change the widths of this and that, and you suddenly have to do maths and change a dozen numbers in the CSS. With constants, you'd just have to change one number.

Also, maybe I'm being overly anal about structure and declarations, but I vastly prefer something like

div#container1 div.header h3 a
div#container2 div.body p a

to

a.container1headerh3
a.container2bodyp

Somehow the former makes more sense to me, and it's much more explicit about the hierarchy and semantics. I've dealt with the latter several times, although in the form of "a.white", only to find out that I have to go more explicit, anyway, because a change here can alter the appearance there, and I need to duplicate a selector and make it more convoluted.

Re:The W3C needs a big reality check.

[The MESMERIC]

http://www.useit.com/

There, did it for you. Long Live Jakob Nielsen! His work should be made Gospel.

Yes, a very ugly website, but that is not the point. What matters is the essence. He is not there to impress people with visuals but to communicate valuable research and findings without being personally bogged down with achieving the perfect layout himself. His followers are not the public (or the common mediocre webdesigners) - but the best professionals in the industry ever. Ask any real pro.

Note, he does advocate sites to be pleasant looking. He acknowledge his own to be an exception. Read his footnote.

Re:The W3C needs a big reality check.

[19061969]

Real pro (interaction designer / information architect) replying: His site is useful, but pure usability only part of the story. For right or for wrong, layout, colours, graphic design etc all play a role in user experience. Jakob's stuff was ground-breaking a few years ago, but he's rapidly falling behind professional design best practice by focusing only on usability which is way more complex than just usability. He doesn't have the cachet that he used to have.

Re:The W3C needs a big reality check.

[Simetrical]

What do you suppose are the chances that Microsoft itself is slowing down the W3C's progress, for exactly the reason you state?

Zero. Follow the proceedings of the HTML Working Group and see for yourself. You can criticize Microsoft's involvement on various grounds, but nothing they've done has the effect of slowing down progress much. The Working Group is proceeding on a timetable toward Last Call set by the three co-chairs, only one of whom is employed by Microsoft (the other two are Apple and IBM). Microsoft has no more say in the W3C than any other member, and all four of its competitors in the browser market participate more actively in the HTMLWG (and WHATWG) than it does. They wouldn't let it get away with anything even if it tried, which it hasn't.

Standards work always appears slow. With vendor-specific stuff, they don't design it until right before they intend to implement it, and you don't hear about it until the implementation is done. So it sounds like it appears out of thin air. With standards, the design is usually done long before all browsers have the resources allocated to implement it, so it looks like it's taking much longer: you can see the design from day one, and there's a big gap between design and full implementation. Malice has nothing to do with it.

Re:The W3C needs a big reality check.

[Simetrical]

I would bet on it. Look what Microsoft did with OOXML to damage ISO

The W3C is vastly smaller and less bureaucratic than ISO, and also more open. The HTML Working Group conducts its business exclusively on Bugzilla and the public-html mailing list, so if Microsoft were trying anything, everyone would see it. Nothing is done by vote in the HTMLWG, so Microsoft can't try to buy votes secretly. All decisions are made by either the editor (employed by Google) or the co-chairs (one employed by Microsoft, one Apple, one IBM). And everything is being overseen by the W3C administration; you can literally appeal directly to Tim Berners-Lee if you have a problem with the chairs' decision, and people have done that.

Nothing underhanded is going on here. Microsoft can mainly be faulted for not participating much, not for trying to subvert anything.

This makes my job as a teacher easier

[Anonymous Coward]

I teach some courses on HTML/CSS, Flash, etc... I was looking through my materials just yesterday and thought "Hmm. All of these are about xHTML 1.1 and I only briefly mention HTML 5... Should I add more 'Oh, and this is how this thing will be done in HTML 5' stuff?". But with this announcement, I can just postpone that another year or so and they'll still be up to date when compared to latest W3C recommendations. ;)

Re:More evidence of the W3C's increasing irrelevan

[funaho]

Even better, I'd like to see the story of a W3C draft done to the tune of "I'm Just a Bill" from Schoolhouse Rock. Just don't let the W3C do it or they will debate the lyrics for years and not release a draft version until 2020.

No kidding...

[John Pfeiffer]

I can't even use Youtube anymore. Even 360p videos don't play smoothly, and when they go fullscreen (Which isn't really fullscreen anymore) it turns into a slideshow. Forget HD.

AND THERE'S NO WAY TO DISABLE IT. Way to go, Google.

Re:No kidding...

[shutdown -p now]

No way to disable what? YouTube still uses Flash-based video player by default; you actually have to opt in for HTML5 beta, and you can always disable that.

Sound advice

[Ossifer]

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:Sound advice

[SpaceLifeForm]

Evercookie must die!

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.

Deja Vu

[Anonymous Coward]

Are they hoping to repeat the same experience as XHTML 2.0?

Why don't we scrap W3C and go with WHATWG instead? At least they can get the job done. If Apple, Google, Microsoft, Mozilla, and Opera are all in unison I don't see why we need to wait on W3C at all.

Re:Deja Vu

[Anonymous Coward]

...only this time it's a lot more messed up than XHTML 2 was.

Seriously - check out the spec for html5 - even when it's complete it'll be a non-standard standard as you'll be able to mess about with it XML well-formed or not. The point of a standard is, surely, that there is one standard way of doing things?

deja vu indeed.

HTML5 is not there yet.

[drHirudo]

HTML5 will be great, but it is not there yet. I wanted to implement HTML5 for all the videos on my website, but unfortunately, I was unable to find any good HTML5 video player with all the bells and whistles that the Flash players can offer. On top of that, the HTML5 videos players I tested with Flash fallback, were showing the video preview picture without anything suggesting that it is a video, not a picture - for example play button on the center. For the time being I am away from HTML5, even if I like it. I hope they will release decent HTML5 video players soon, that I can easily replace with the Flash, but have the fallback modes for the people with old browsers or mobile devices.

Re:HTML5 is not there yet.

[shish]

HTML5 will be great, but it is not there yet

You've described wonderfully what's wrong with HTML5 video, but what about the other 99% of the spec?

This isn't the W3C.

[R.Mo_Robert]

...just a guy who happens to be part of the W3C 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:This isn't the W3C.

[bigredradio]

And he's French.

Re:This isn't the W3C.

[Simetrical]

...just a guy who happens to be part of the W3C 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?).

A guy who "happens" to be leader of the entire Interaction Domain, including HTML (and CSS, SVG, etc.). So, yes, it's not an official W3C statement, but Philippe Le Hégaret is not just "a guy who happens to be part of the W3C".

and MS buys favor, again.

[swschrad]

Hey, browser makers. this one's for you. do you correctly render the HTML5 tests? then you need to order now, within the next 5 minutes. you need Get A Clue (tm)! yes, the world is leaving you behind while you hold focus meetings and task offsites. Get A Clue (tm)! Get A Clue (tm) will motivate you to read the damn spec and get back in the market! you can't afford to miss this deal! operators are standing by, get your credit card out now! Get A Clue (tm)! order now!

Re:and MS buys favor, again.

[Anonymous Coward]

well here's a big chance for you to get a clue - most browsers don't support html5 and they won't in the future. Moan as much as you like.

And like it or loath it, for most businesses and organizations the likely survival of IE6 etc means that support for the way it renders content is an important part of their approach to the web, whatever the impact on transient technologies and standards.

IE9 won't work on xp - is it any wonder the w3c can't recommend html5. I mean come on!!!!

Most web devs i know (including myself) think that there is nothing behind the hype. HTML5 is a PR stunt, it's more marketing than IT
it's just another markup language - and one that's worse specced than XHTML 2 was.

A more practical alternative

[Tumbleweed]

Use HTML 4.01 STRICT DTD. Strict fixes the IE6 box model problem, which is _huge_.

Use a CSS reset to make all browsers start with a consistent base style which you then define.

Use Clearfix so you can clear floats without having to insert extra HTML (a div clear class which I see people use all the time).

Either make up your own commonly-used CSS styles, or use something pre-made like 960.

Use DD_Roundies to give IE rounded corners and give IE6 alpha transparency for PNGs. (avoid absolute positioning with this until this bug is fixed.)

Use whichever js library you want so you only have to do one set of js for all browsers.

This gets you 99% of the way to where you want to be, generally.

Finalize the spec prior to release to public

[Anonymous Coward]

As a professional web application developer, I agree with the W3C on this one. Apple is quick to push HTML5 because it has some odd fascination with hating flash. HTML5, however, does not do everything that flash can do. Furthermore, there are security implications within the draft spec.

Standards need to be approved for professional applications. Sensitive sites like banks, hospitals, heck sites that store and use any personal information need to be secure. By introducing hacks and branches either within code or within the browsers themselves can lead to security vulnerabilities that are unknown. In addition, if the spec changes and browsers have implemented something based on the draft that gets changed it can have a huge impact.

For example, let's say company A writes a web application based on IE9 that uses canvas in a certain way throughout the application. The canvas spec gets changed before the HTML 5 spec is ratified. The cost to update the code to work in the new IE 10 or 11 or whatever is out at the time is a couple of hundred thousand dollars. This company will now stick with IE 9 because it works. It will be like IE6 all over again and people will never get off of the older versions. The same scenario can happen with Firefox or Chrome.

In addition, professional site development will incur extra costs across the board. More QA, more development to make all the hacks work, more security testing, more load testing, etc. So companies will a) not do the extra work and the site will be insecure, not always work, etc or b) incur the cost and pass it to consumers in some way either more ads or higher costs.

Lastly, and this is my pure developer rant here, HTML and javascript needs to be thrown out in total. Updating these dated technologies and ideas doesn't really address what the web is today. For example, it would be nice to componentize HTML structures for reuse. The technologies (including IP, HTTP, FTP, etc) need to be rewritten to be more flexibile to change with the times as oppossed to holding everything back. Modern web apps would do well with more secure implementations of languages and sandboxing the web to a specific domain in order to make it more secure. Right now flash and active x and java applets can be hacked to gain full system control. But some apps would be better served with offline storage and the ability to work offline. However, the user needs to be able to remove the items in the storage area easily. HTML local storage is being exploited TODAY with tracking information that users can not remove easily. Delete all the cookies you want, it will not delete local storage. See the following links why it needs to be standardized first: http://www.scribd.com/doc/4012693/Abusing-HTML-5-Structured-Clientside-Storage and http://arstechnica.com/tech-policy/news/2010/09/lawsuit-targets-advertiser-over-sneaky-html5-pseudo-cookies.ars. But yeah, let's just move ahead and screw the consequences.

I'm really blaming Apple here for pushing this so hard. Now all my clients are aware of HTML 5 and think it is the best thing since sliced bread. Until I educate them that it is a draft spec with large consequences. Apple is certainly making my job more difficult. And what about developers who are unaware and implement HTML 5 as per a client without educating them? Who the heck is going to pay for all of the consequences of that? Is Apple going to set aside an HTML 5 rush to implement disaster fund?

No need to rush

[oiron]

I can't find anything on the tubes about this apart from the infoworld article (and its mirrors on apparently every site ending with -world.com). We don't know what he's actually said, and/or what his reasoning was.

If he was saying something like "Don't rely on HTML5 being fully implemented just yet, because various things are subject to change", that's just understandable. He may not be saying "don't use it" - just "don't rely on it", or "don't use in a production environment that has to work for the next 20 years unchanged".

Sensationalist article, no corroboration.

html5 vs xhtml2

[Nadaka]

I thought that one of the big factors in adoption of html5 vs the superior xhtml2 spec was that html5 was here now?

Re:html5 vs xhtml2

[shutdown -p now]

HTML5 is here now in a sense that large parts of it are effectively standardization of existing features implemented in today's browsers. It's not "here now" in its entirety.

In contrast, XHTML2 was not implemented by any browser when it was ratified as Recommendation. What more, all browser makers that were asked explicitly stated their disinterest in implementing it.

Re:html5 vs xhtml2

[Stefan]

XHTML 2.0 was abandoned before reaching recommendation status, it only got to "working draft" status, last update was 2006.

Avoid

[proxy318]

avoid the draft HTML5 spec (the final version is not due for several years) because of interoperability issues across browsers."

That's different from HTML4 how, exactly?

Rest of the World Says Get W3C's Ass Moving

[Blakey Rat]

HTML5 was going at lightning pace (relative to any W3C work) until the W3C took it over, now it's stalled to a near-halt. Screw them, at this point they're more holding back progress than increasing interoperability.

Use HTML5, just be prepared to make changes to your app if needed.

Re:More evidence of the W3C's increasing irrelevan

[TheRaven64]

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

[TheRaven64]

The W3C is not really running the HTML 5 standards process. The reason it is taking so long is that each part of the spec must first have a well-defined need that it addresses and must then have two independent implementations before it can move to final status. It takes a while for two browsers (usually WebKit and Gecko) to implement something new, to find problems (i.e. unimplementable bits) with the draft spec, then for people to start using it and test whether it really does address the defined need.

Re:More evidence of the W3C's increasing irrelevan

[TheRaven64]

First off, Canvas is fucking redundant and never should have been created in the first place. SVG has existed since 2001

Canvas and SVG are very different. Canvas uses an imperative model, SVG uses a declarative model. Your comment is like saying we don't need OpenGL because we have VRML. Some things are much easier to implement with canvas, some are much easier to implement with SVG.

Who listens to the W3C?

[Anonymous Coward]

If everyone listened to what the W3C says, we would have never had bad browsers which don't follow standards and sub standard markup everywhere on the internet.

Tendency Toward Perfection

[NicknamesAreStupid]

There is a heartfelt intention among certain members of standards bodies to want to produce something that is 'right' or 'robust' or 'logically consistent' or any number of other noble qualities that characterize enduring standards. In committee, these people carry a lot of weight with sound arguments and endless examples of lesser works. They often prevent huge holes or flawed assumptions from undermining these long and complex works. Of course, they slow things down, too. The problem comes down to continuing performance. In this world, whatever is approved now will probably be partially obsolete before it can become a big enough problem to matter. In this case, as with life, perfection means being to be able to adapt as quickly as things change.

Re:More evidence of the W3C's increasing irrelevan

[Anonymous Coward]

._. The original plan of WhatWG was to stabilize in 2022 . Yes. 12 years from now. But the devil is in the details and I am not 100% up to date on the W3C details. I get the feeling that the W3C is trying to be the Debian of standardization organizations though. Slow and stable.

Re:More evidence of the W3C's increasing irrelevan

[microbee]

Standard bodies always fall behind. If you count on them nothing can be done.

For the same reason, let's not abuse the 'standard-compliance' weapon either. We criticized that IE wasn't standard compliant for a long time, and that was not all for a good reason.

Sounds like an Adobe plant

[daggre]

This is crazy - the only good reason I can think of that the W3C would say to wait is if Adobe paid somebody off to say that. There's a NEED immediately for cross-platform media that HTML5 provides today. The only other solution to this immediate need is to use Adobe Flash, and it's already a complete fail in the mobile space (including Android, which is absolutely horrible at running Flash content that's not specifically designed for use on mobile devices). They need to accelerate the finalization of the media aspects of HTML5 immediately, and call everything else HTML5.1 or HTML6, then let THAT come out in 3 years. To wait until 3 MORE iPad and iPhone hardware releases have been shipped, not to mention who knows how many Android devices, not to mention Windows Phone 7 (well, ok, we can probably safely not mention Windows Phone 7 since it has Silverlight as its focus) there's just not 3 years to wait, guys.

Re:More evidence of the W3C's increasing irrelevan

[DeadboltX]

Maybe if manufacturers didn't flood the market with incompatible pre-n and draft-n devices then there would have been more urgency in ratifying the standard.

Not entirely unexpected but still...

[Anonymous Coward]

Almost every web developer i know was expecting the cloud of hype around html5 to evaporate, but not many of them expected it to happen so quickly.

At the end of the day this isn't a day too soon - it will probably save us devs a lot of time.

html5 {
position: indifferent;
display: eventually;
overflow: 5yrs;
padding: 3yrs;
background: #eeeeek url('http://ishtml5readyyet.com/') repeat-daily;
}

Password masking is the bug

[tepples]

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

Not a bug. Password masking itself is the bug.

Re:Password masking is the bug

[LordLucless]

Sorry, but that's just wrong. Sometimes Nielsen has good stuff to say, but at other, he just seems out of touch:

More importantly, there's usually nobody looking over your shoulder when you log in to a website. It's just you, sitting all alone in your office, suffering reduced usability to protect against a non-issue.

Who has an office? I don't. Most of my friends don't. If you log in at work, your screen is generally visible. Ditto for on your laptop when your commuting. Home is the only safe place.

In cases where there's a tension between security and usability, sometimes security should win.

Sometimes security should win? Usability's important, but I think Nielsen is over-emphasizing its importance because its his person crusade.

It's therefore worth offering them a checkbox to have their passwords masked.

His solution? Default to insecure and require user-interaction to increase it. Yeah, that's going to work.

Re:Password masking is the bug

[daveime]

Sorry, but anyone who really wants your password that badly will either :-

Look at the keyboard rather than the screen.
OR
Install a damn keylogger.

Besides, the majority of users will use the same password for everything, and it'll most likely be "12345" or "swordfish" anyway ...

Do we really need this simple obfuscation that contributes NOTHING to real security ?

In this case, I tend to agree with Nielsen.

Re:Password masking is the bug

[LordLucless]

Password masking isn't designed to stop the dedicated/skilled hacker. It's designed to stop the casual - the guy walking past your desk who needs one glance to see your full password sitting there in all its plain-text glory.

If you need to be able to view it, there are plenty of options for doing that without having the whole password there for anyone to see at any time. Show the password masked, except for the last character. Show the full password only if you mouse over it. At the very lease, default to masked and allow the user to toggle it off rather than on.

Re:More evidence of the W3C's increasing irrelevan

[nicolas.kassis]

"Pretty much anything that isn't canvas or video isn't implemented anywhere" That statement is pretty inaccurate, many of the features in HTML5 are already available and things like WebGL will be available by year end (Firefox 4, Chrome 7). In fact, I'm already building software with WebGL which has actual users.

Engineers vs. Developers

[Anonymous Coward]

I think this highlights the major differences between engineers (who often design, architect, and specify systems) to developers (who implement (sometimes architect-ed :P) designs and specifications...

W3C may want us to hold off because they're worried about varying compliance between vendors on their already variadic specification.

Developers don't care, developers want to get started, want to start implementing, and want to get said specification WORKING in the real world... dig into the compatibility differences between each other from day one, to help sort things out and identify issues in the specification & implementations.

I dare say W3C is just procrastinating like most engineers.

The real reason HTML5 is not ready yet.

[master_p]

The real reason that HTML5 is not ready yet is the nature of HTML: it is a set of instructions that must be interpreted with 100% accuracy from all involved parties, which is something extremely difficult, if not outright impossible.

If HTML was an API, then its behavior would depend on the API's implementation, which is much easier to fix than a specification: an API is a testable specification, because it's code that can run and be tested; an on-paper specification cannot be executed until it is transformed to code.

The only realistic solution is to make HTML an API for a programming language that the browser understands. In this way, the meaning of each tag and of each attribute will be completely defined by code, and thus it will be much easier to change or throw away.

Some past engineering challenges

[PapayaSF]

Compare the time it's taking to finalize HTML5 with some past engineering challenges:

• The first prototype Jeep was designed and built and delivered for testing in about two months by the tiny and bankrupt American Bantam Car Company, which had to hire a freelance engineer for the job because they no longer had an engineering staff.
• The first P-51 Mustang, which eventually became the best all-round fighter of the war, was designed and built in 117 days.
• The Empire State Building was built in about 18 months.

Is HTML5 really so much more complicated?

Re:More evidence of the W3C's increasing irrelevan

[kn]

I totally agree. The W3C will surely lose relevance if they don't seriously wake up. It has already begun with WHATWG's work being the basis for HTML5. W3C only holds onto an strand of credibility by their decision to eventually back HTML5.

W3C has lost sight of the things that put them into the position of a governance body. I believe that they have failed to understand that their authority comes from the widespread support of their standards, not their control over the standards. When their standards no longer have widespread support, they cease to be the standards body, just as in the case of WHATWG with HTML5.

Something similar happened with Xfree86 and X.org, and it's looking to happen with W3C in the future, of course with differing catalysts.

Looking at W3C's work over the last few years, it appears as though there is too much theoretical and not enough practical in their recent specifications (before HTML5). The resultant works have been overly complex without any significant benefits, and I use the term resultant lightly, noting that works almost never reach completed stage, which is a joke in itself.

Too many cooks in the kitchen, perhaps, and not enough oversight by people with common sense.

maybe

[shentino]

A large part of the difficulty is political wrangling about who gets to push their features into HTML5.

We never did settle on a standard video codec because everyone was squabbling about who got to pick.

They blew it...

[Kensai7]

If the W3C says don't use HTML5 yet, they blew it. :p

Re:More evidence of the W3C's increasing irrelevan

[Anonymous Coward]

Don't forget 802.11i too. What would happen if instead of having WPA, we had to wait for the final ratification of 802.11i to get anything better than WEP?

Re:More evidence of the W3C's increasing irrelevan

[Simetrical]

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

Re:More evidence of the W3C's increasing irrelevan

[Simetrical]

._. The original plan of WhatWG was to stabilize in 2022 . Yes. 12 years from now. But the devil is in the details and I am not 100% up to date on the W3C details. I get the feeling that the W3C is trying to be the Debian of standardization organizations though. Slow and stable.

The WHATWG never planned to stabilize in 2022. Ian Hickson, the editor of HTML5, predicted that it would take until 2022 to reach the equivalent of W3C Recommendation status: where every single feature has at least two independent implementations, plus a full test suite (which would require hundreds of thousands if not millions of tests for such a large spec). The spec becomes basically stable at the Candidate Recommendation stage, which Ian originally predicted to be 2012 (and that looks to be plausible so far). You can read more about this in the WHATWG FAQ.

Re:More evidence of the W3C's increasing irrelevan

[Simetrical]

In a work placement year I did the major electronics company had a couple of staff on the board for a standard -- it involved lots of XML and internet stuff, so it's not far from the kind of thing W3C does.

What took so long was working out whether technology that required infringing on each company's software patents should be "required" or "optional". In the end, Sony, Philips, Panasonic etc decided to pool their patents (their stuff is "required"), the patent troll companies were excluded by the big company's votes (so the neat technology they'd patented was "optional" or left out entirely) and the couple of small businesses or individuals who'd already got products running using the draft spec were ignored.

The W3C has a Patent Policy requiring that all its specifications be implementable royalty-free, so this is not an issue. No spec can be covered by any known patents at all unless those are irrevocably licensed royalty-free. I've heard this kind of bickering can suck up time at less enlightened standards organizations, though, which believe in unreasonable stuff like RAND (= let everyone on the standards committee rake in money by making sure some patent of theirs is required).

HTML5

[plh_w3.org]

I wrote a blog entry on this subject for those who are interested: http://www.w3.org/QA/2010/10/html5_the_jewel_in_the_open_we.html -- Philippe Le Hegaret