This was a free event with several speakers covering several aspects of the draft HTML5 standard. It wasn't an ideal venue for presentations as there was a big pillar in the middle of the room, and as a result I couldn't see the right hand side of most of the presentations, but I think I got the gist of it.

HTML5: Are you mything the point? - Bruce Lawson

Bruce covered several popular misconceptions people have about HTML5:

• Evil browser vendors dominate - while they do have a lot of influence, because ultimately it's the browser vendors who have to implement it all, the key point is that all the browser vendors are collaborating so they'll all be implementing the same standard. Also the spec takes a 'pave the cowpaths' approach - if browsers already support it, and it is in common use, the spec defines and legitimizes it - for example the embed element.
• Hello tag soup, goodbye XML - while it's true that you don't have to close elements if you don't want to (unless you're using XHTML5), the HTML5 spec defines what browser should do with invalid markup, so invalid markup should look the same in all browsers.
• Kills Flash/Silverlight/Javascript - while it provides an open alternative to Flash and Silverlight, they're not going away any time soon. The Javascript one is a bit hard to understand, but Bruce had been asked about it several times so he felt it was worth mentioning - HTML5 provides several things which replace the need for lots of the 'little' stuff that JS is currently used for, eg. the details element.
• It'll break the intertubes - HTML5 has been designed to be backwards compatible and the choice between several options has been decided by what works in current browsers: for example many people wanted the href on arbitrary elements but this didn't work in any browser; however allowing the a element to wrap arbitrary content does work, so that's what's in the spec.
• It hates accessibility - the philosophy behind the WHATWG's approach to accessibility is to build it in to the elements, for example the new form elements provide lots of extra data and functionality, so the accessibility happens without any special effort by the author, while the approach taken by ARIA is more to 'bolt on' accessibility. Of course, there are some issues with this approach - ARIA can do a lot of things HTML5 doesn't support, and assistive technologies already support ARIA, while the AT suppliers have not gotten involved in the HTML5 spec process despite being invited.
• Can't use it until 2022 - in fact a loot of it can be used right now, even in Internet Explorer. The definition of 'ready' comes from a misinterpretation - Ian Hickson was asked when the spec would be finished, since 'finishing' requires two complete and fully interoperable implementations he said it wasn't likely to be finished until about 2022.

Bruce then discussed several of the new elements in HTML5, many of which I covered in my earlier blog post, the outlining algorithm (so you can have multiple h1 elements in the page), and then covered the new form elements - now supported in Opera 10 beta. The forms stuff looks quite cool, so I'll try and do a full post on that in a few weeks.

HTML5.js - Dean Edwards

Dean is the creator of ie7.js, a script "to make Microsoft Internet Explorer behave like a standards-compliant browser" and now he's done it again with html5.js, a script which adds support for HTML5, including all the new structural and form elements to browsers which don't currently support it. He did a very impressive demo, which included demonstrating all the form elements inheriting the windows theme and rendering correctly. There was some discussion about how he'd achieved all this, and Dean admitted to "quite a lot of browser sniffing," but "the good kind of browser sniffing."

Javascript APIs - Remy Sharp

Remy gave an overview of several of the new APIs in the HTML5 spec, including some which are now in separate specs:

• Canvas - supported in every major browser except IE, and even there you have options.
• Drag and Drop - Supposed to work in Firefox, Safari and Opera, but Remy had only managed to get it working in Firefox. Instead of writing a whole load of javascript to implement drag and drop, in HTML5 you just declare draggable=true on an element and then hang some functions off the dragstart and dragend events.
• Offline Apps - one of the most interesting possibilities presented by HTML5 is the possibility of offline web applications. Native support is coming in Firefox, Safari and Opera and is available already, sort of, in other browsers thanks to Google Gears. Remy covered the application cache, online and offline events, the navigator.online flag (which, unfortunately, only appears to work in Firefox) and the cache manifest file.
• Geolocation - supported in the latest Firefox and the iPhone version of Safari and in other browsers, again, sort of, by Gears. The interface is fairly simple, just call getCurrentPosition and pass in a callback function.
• Messaging - an API to pass messages between pages in different domains, supported by all the latest versions of the major browsers (even IE). Remy showed us the postMessage function and onMessage event, and discussed some of the security features.
• Web Workers - threading for Javascript, supported by Chrome, Firefox and Safari and also another feature of Gears.
• Storage - actually two different types of storage: key/value stores for both the window and the domain plus a SQL storage engine, sessionStorage, localStorage and Database respectively.

Remy has several examples online if you want to have a more detailed look.

The HTML5 Canvas Element - Martin Kliehm

The bulk of this presentation was made up of a bunch of demos of really cool stuff done with the canvas element, so a bit hard to describe in a blog post and keep things short. Hopefully it'll appear online shortly, in the meantime this is one of the more blogged about and well known parts of HTML5 so I'll not go into details. Martin discussed several 'fake 3D' rendering techniques, some of the performance advantages over stuff like SVG as well as some of the possibilities to come once full 3D support was available.

HTML5 Accessibility - Steve Faulkner

Steve started off with a couple of entertaining slides illustrating the contrast between what he thinks is important as far as accessibility in HTML5 is concerned and what has seen the most discussion. So far everything has centred around whether or not to require the alt attribute and various apocrypha of tables, where it needs to discuss ARIA, the canvas element and text alternatives. So while so far things have not been so great there is a great deal of potential in HTML5. All the extra semantic elements (header, article etc.) can provide additional information to assistive technologies, as will the new form controls. While canvas and the new video element don't currently offer much (canvas is worse than Flash - fallback content placed inside of it simply disappears as far as ATs are concerned), having these elements as first order members of the DOM presents opportunities in the future for screen readers and other technologies to interact directly with media experiences at a deep level. Steve then discussed the compatibility (or otherwise) of HTML5 with ARIA - after some argument the validator accepts valid ARIA attributes and browsers already implement support in HTML5 anyway, so in many ways it doesn't matter whether the WHATWG adds specific support. He finished off with some slides showing the level of browser, screen reader and Javascript library support for ARIA (IE, for once, leading the pack in a standard alongside Firefox, Dijit leading the way in libraries - though several major JS libraries were surprisingly good).

This was a great event, in spite of the pillar, and I've just skipped over a lot of it (we overran by more than an hour ) so 5 out of 5. Watch the website for news of future events in the series or follow #standardsnext on Twitter.