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

Comments

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. (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: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/
http://www.webstandards.org/action/acid3

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

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]

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.