This Summer in HTML 5 – Episode 33
I hope you enjoyed your summer. My oldest son started kindergarten today. Let's talk about HTML 5.
When last we checked, HTML 5 was humming along towards Last Call in October. Much has been made of this date; I won't bore you with the details, except to say that HTML 5 is very close to entering the next phase of its existence. Regular readers of this blog already know that parts of HTML 5 are already shipping in major browsers. The recently-released Firefox 3.5 supports <audio> and <video>, offline web applications, the drag-and-drop API, and the <canvas> text API. (Technically Firefox 3.0 supported the <canvas> text API too, properly cordoned off in its own vendor-specific functions because the API was not finalized at the time. You can paper over the differences fairly easily.)
So what new and exciting stuff has been added to HTML 5 this summer?
Microdata
At the table in the kitchen, there were three bowls of porridge. Goldilocks was hungry. She tasted the porridge from the first bowl. "This porridge is too hot!" she exclaimed.
So, she tasted the porridge from the second bowl. "This porridge is too cold," she said.
So, she tasted the last bowl of porridge. "Ahhh, this porridge is just right," she said happily and she ate it all up.
— The Story of Goldilocks and the Three Bears
r3074 introduces the concept of microdata. Microdata is designed to allow authors to include additional semantics in their pages for which there is no appropriate HTML element or attribute. For example, HTML is not expressive enough to mark up a contact in an address book (complete with individual fields for name, street address, email, and phone number) or an event on a calendar (complete with start date, end date, and location). Instead of creating new elements and attributes for every possible vocabulary, you can use the microdata attributes to enhance existing elements.
There are a number of other technologies with goals similar to microdata, including microformats and RDFa. As Ian Hickson explained in the message "Annotating structured data that HTML has no semantics for" that introduced microdata, microformats are fine for specific formats but are not flexible enough to be parseable by a generic parser, while RDFa relies on CURIEs and XML namespaces in a way that would require changes to HTML parsing algorithms to work interoperably between text/html and application/xhtml+xml. (Forgive me if I didn't explain that very well. There was a lot of yelling and very little explaining once it became clear that RDFa was not going to be included in HTML 5, so I probably missed some of the nuances.) Work is ongoing to create an RDFa-in-HTML specification.
ARIA
ARIA stands for "Accessible Rich Internet Applications." It is an emerging standard for making web applications more accessible to people using assistive technologies (including, but not limited to, blind people who browse the web with the help of screenreaders). The basic technique is for authors to define "roles" and "states" on individual elements to indicate what sort of control the element represents. For example, HTML has no "treeview" control, but JavaScript libraries like Dojo let you include a treeview in your web-based application with a combination of generic HTML elements, a few images, and a whole lotta JavaScript. ARIA gives you a way to say that the "treeview" HTML element (which is probably just a <div>) is acting as a treeview (that's its "role"). Each item in the treeview can be in the "expanded" or "collapsed" state, and the state changes as the user interacts with the control. Major browsers, including Microsoft Internet Explorer (8) and Firefox (2+) will notice the custom role on the element and announce to assistive technologies that this <div> element is acting as a treeview. (In fact, Dojo already supports these roles and states, due to work funded by IBM.)
r3657 adds the section Annotations for assistive technology products to HTML 5. There are still a number of unanswered questions about how the custom semantics defined by ARIA interact with the native semantics defined by HTML 5.
Everything Old is New Again
As regular readers of this blog already know, HTML 5 goes to great lengths to specify existing browser behavior, even to the point of "willfully violating" other specifications. Vast stretches of the HTML 5 specification are devoted to elements, attributes, and scripting features that nobody likes but everyone is required to support. To that end, r3502 defines the <listing>, <plaintext>, <acronym>, <xmp>, and <dir> elements; r3133 and r3141 define the <marquee> element; r3155, r3403, r3409, and r3410 define document.all.
Other important changes include the location.reload() method (r3220), the textarea.textLength property (r3177), a new rollback() method for synchronous SQL transactions r3210), and the ability to upload multiple files at a time from a web form (r3544 and r3545).
Features Removed
"The food here is terrible!"
"I know, and such small portions!"
(variously attributed)
Everyone complains that HTML 5 is too big, but nobody has any reasonable solution for making it smaller. (Splitting it into multiple specifications to make it "smaller" is like cutting a pie into slices to give it fewer calories.) However, based on implementor feedback, HTML 5 has shed a few poundsfeatures this summer. To wit:
- r3555 removes the
<datagrid>element and its associated APIs. Originally envisioned as a two-dimensional editable "spreadsheet-lite," it was never implemented in any browser. - r3621 removes the
<bb>element, which was originally designed to support "installing" web applications as standalone programs. There were a number of security-related concerns, and browser vendors flatly refused to implement it. - r3342 removes any mention of what an optimal video codec would look like. Contrary to popular belief, this revision does not remove the
<video>element itself; the<video>element is alive and well and implemented in Safari, Firefox, Google Chrome, and an experimental build of Opera. However, it is true that there is no single video codec that is supported out-of-the-box by all browsers. Firefox and Opera only support Ogg Theora, Google Chrome supports H.264 and Theora, and Safari supports whatever QuickTime supports (which doesn't include Ogg Theora unless you install a third-party plugin).
Administrative Stuff
"Man didn't the right form."
"What man?"
"The man from the cat detector van."
"The loony detector van, you mean."
"Look, it's people like you what cause unrest."
When web servers send you HTML, they are supposed to label it as such with the HTTP Content-Type header. Each content type (an HTML page, a JPEG image, an MPEG-4 video) has its own "MIME type." MIME types must be registered with the IANA.
r3552 adds the registration information for text/html, application/xhtml+xml, text/event-stream, text/cache-manifest, and application/microdata+json. r3582 adds the registration information for text/ping.
Standards frequently include references to other standards. References can be "normative" or "informative." To quote RFC 3967 (a standard about creating standards), "a normative reference specifies a document that must be read to fully understand or implement the subject matter in the new [standard], or whose contents are effectively part of the new [standard], as its omission would leave the new [standard] incompletely specified. An informative reference is not normative; rather, it provides only additional background information." r3580 adds a list of references to HTML 5.
Tune in next week as we return to our regular weekly schedule of "This Week in HTML 5."