W3C Publishes First Public Working Draft of HTML 5

Lachlan Hunt writes "Today W3C announced that the HTML Working Group has published the first public working draft of HTML 5 — A vocabulary and associated APIs for HTML and XHTML. It's been over 9 months since the working group began in March 2007 and this long awaited milestone has finally been achieved. '"HTML is of course a very important standard," said Tim Berners-Lee, author of the first version of HTML and W3C Director. "I am glad to see that the community of developers, including browser vendors, is working together to create the best possible path for the Web..." Some of the most interesting new features for authors are APIs for drawing two-dimensional graphics, embedding and controlling audio and video content, maintaining persistent client-side data storage, and for enabling users to edit documents and parts of documents interactively.' An updated draft of HTML 5 differences from HTML 4 has also been published to help guide you through the changes."

Re:Not again

[timbck2]

When IE6 decreases to 10% or so, the last of the really non-compliant browsers will be history.

Which shouldn't be a terribly long time:

http://it.slashdot.org/article.pl?sid=08/01/21/0652248 [slashdot.org]

Re:Of course, it won't matter.

[AKAImBatman]

Of course, it won't matter. At least until some major browsers support it.

Several of the features (e.g. Canvas) are already supported by all major browsers save for IE.

And it really won't matter until IE supports it.

One of the interesting aims of the HTML 5 standard was to spec the new functionality in such a way as to make it possible to emulate the new APIs in old browser. e.g. Canvas working in IE. [dnsalias.com] (Make sure you click outside the block area to start. I haven't implemented the key passing yet.)

The Storage APIs would be similarly easy to emulate through Cookies, Flash, or Google Gears. (Take your pick.) Server Side Events are more difficult, but I think it might be possible to emulate with XMLHttpRequest. If I'm wrong, there's always a Flash or Java shunt possible. DOM 2 Events is still not supported by IE, but that's easy enough to patch for by wrapping IE's attachEvent scheme.

Basically, we can force Microsoft's hand on this. A simple runtime patch and BAM, we're coding to HTML 5 standards. If enough people do it, Microsoft will realize they've lost that front and move on.

Re:HTML5 is the wrong path

[hixie]

XHTML failed: hardly anyone uses it. According to studies I did at Google, using a sample of several billion pages, about 0.0044% of pages use XHTML with the XML MIME type, and about 15% of people try to use XHTML, by giving the XHTML namespace, but actually use HTML, by sending it with the text/html MIME type.

I'd rather work on a spec that is considered drivel but that everyone ends up using, than work on a spec that is theoretically perfect but which makes zero impact on the world at large.

Re:Of course, it won't matter.

[hixie]

The browser vendors are part of the working group, so they would be part of any discussions as to what to change. In practice, it's actually the browser vendors who request the changes -- typically, it's because the spec requires things that are contradictory or that don't really work in the real world for one reason or another, and the browser vendors thus would rather implement something else. The requirement for waiting until we have 2 complete implementations is so that we know, when we say the spec is done, that it really can be implemented and that such implementations really can be interoperable.

Re:Not again

[hixie]

Most of HTML5 was actually done outside of the W3C.

However, to address your earlier point, one of the big things we're doing with HTML5 is we're going and specifying the bits that all the other specs avoided, like 'window', like 'setTimeout', like how to parse HTML in the face of errors, and so on, and saying exactly how they should work, based on how browsers do them now, so that we can get the browsers to converge on one interoperable set of behaviours.

I'm also working on the Acid tests, e.g. Acid2 and Acid3, to foster interoperability on the older specs. It's working pretty well so far.

http://ln.hixie.ch/ [hixie.ch]
http://www.webstandards.org/action/acid3 [webstandards.org]

So... HTML5 should actually help bring the browsers closer on the bits that weren't specified before, and the Acid tests are directly intended to do that with the bits that _were_ specified before. If you want to help out, please do -- see the links above for how to help with Acid3, and the links below for how to help with HTML5:

http://blog.whatwg.org/w3c-restarts-html-effort [whatwg.org]

Re:no default ogg, sadly...

[nickptar]

"We now have AAC/MPEG-4 part 3 for audio and H.264/MPEG-4 part 10 for video"... both of which are patent-encumbered.

Re:The treadmill....

[hixie]

HTML5 is the furthest thing from committee-driven development in the W3C. Basically, I'm a dictator and every piece of feedback goes through me. (This is a point of contention with a lot of people who disagree with my approach, which has basically been to focus on use cases, pragmatic arguments, and research, and to eschew "expert opinions" as the sole guide to what the spec should say.)

Also, spec writers aren't in charge of anything. This is actually a common fallacy, which leads to people writing specs without paying attention to their users and implementers -- just look at most specs coming out of the W3C. No, spec writers are in fact at the very bottom of the food chain. We can only specify things which the implementers want to implement, otherwise they'll ignore us, and we are only able to control what users do in so far as we tell them to do things that they want to do, otherwise they'll ignore us too. Just look at browser vendors ignoring specs they disagree with. Just look at how many pages have some sort of syntax error (over 93% according to a study of several billion documents I did last year).

With HTML5 we're specifically trying to avoid torpedoing what implementers and users are doing today. A huge part of the effort is to make the spec relevant, specify what users are doing, specify things that other specs left vague, add features where users are working around holes in the spec, etc.

As to whether my job is a "real job" or not... I can't speak to that. It's a lot of work, at least. :-)

Re:Not again

[mhall119]

Yes, let's roll out another new standard for no reason at all when most of the web still hasn't caught up to the last one.

I read the spec, and most of the additions are to incorporate what we've all been doing, with CSS/Javascript hacks and plugins, into the spec itself.

• Menu tag: An actual menu element provided by the render engine, no more CSS/Javascript menu libraries
• Combo-box input: An actual combo-box form input field, no more CSS/Javascript hacks
• Datetime input: No more javascript libraries to popup a date chooser, it comes with the browser
• Number input: No more javascript intervention to stop you from typing "bob" into a field expecting a number.
• Email input: Not only can it validate email format, but it could let you pull from your email client's addressbook
• URL input: Again, not only validation, but could let you pull from your browser's favorites, history, etc
• Input validation: No more onSubmit javascript checks to make sure your required fields have data in them.
• All Inputs have min/max and pattern (presumably regex) restraints

(BTW, all of the above should work even when Javascript is disabled, so you NoScript users get security _AND_ functionality)

• Datagrid: An actual data grid widget, no more hacking Tables to provide the same functionality
• Audio/Video tags: Just like <img/> tags, only for other media, what a concept!

Re:HTML5 is the wrong path

[hixie]

They don't (IE doesn't do XHTML), and I'm also not convinced that XHTML is necessarily the superior one.

Re:Not again

[hixie]

(I'm the HTML5 spec's editor.)

What you describe seems more like a stylistic thing than a semantic thing (e.g. it wouldn't really make much sense in a speech browser, as far as I can tell). I recommend suggesting it to the CSS working group.

Re:HTML5 is the wrong path

[Dracos]

No version of IE supports XHTML's correct mime type. XHTML "failed" not because people didn't want to use it, or didn't understand it, but because the majority browser didn't support it. So XHTML is served with the mime type IE does understand, and this is a practical, if far from ideal, compromise. The problem lies with the browser(s), not the users or developers.

I'd rather have a spec that is perfect and correctly implemented than a perverted one that still won't be correctly implemented.

Re:No more "td align"

[TrebleJunkie]

Uh, no you won't get people doing that, because they're removing the style= attribute. (See a previous reply of mine to learn exactly how stupid I think that particular move is.)

Re:HTML5 is the wrong path

[hixie]

Well, we need tables to be able to represent tabular data. How else would you, for example, represent an invoice? Or a timetable? There are certain things for which tables make sense.

Naturally, semantic tables should never be used for layout purposes, and that has never been allowed by any of the HTML specs.

Re:First thoughts

[hixie]

There's no difference between XHTML1 and XHTML5. They have identical processing requirements. You don't need to distinguish them.

I'll see about adding a sentence to remind authors not to rely on script if at all possible.

HTML5 adoption hasn't really started yet, but that's a good thing, we're nowhere near ready for adoption. Even basic things in the spec are still changing in big ways at the moment. There have always been plans to write shims for adding HTML5 support to IE, e.g. http://excanvas.sourceforge.net/ provides <canvas> support in IE today, so that you can use <canvas> in all browsers. It's early days still as far as that goes. We can add support in this way for many features, in ways far easier than for XHTML.

Re:very sad

[hixie]

The HTML5 spec includes an XHTML variant, just like it includes a text/html variant. The spec itself is agnostic about which you should use, you can use whichever one you want.

Re:HTML5 is the wrong path

[hixie]

HTML5 has a defined parsing model and is not actually any harder or slower to parse than XML. In fact, I have heard implementors from several browser vendors say that HTML5's parser spec is easier to implement than XML, and that there should be no performance difference.

There are also a growing number of HTML5 parsers out there, including some for Python, Ruby, and Java, with more being written. The spec makes it actually really brain-dead easy to implement an HTML5 parser that is compatible with Web content, and a big test suite has developed around it which makes tracking down bugs even easier.

Regarding <br/> vs <br>, HTML5 allows both in text/html (though the / has no effect, it's just ignored).

I've put XHTML tests into Acid3, so hopefully that will convince Microsoft to get with the programme and support it. We'll see.