Sometimes, new authors need a gentle reminder to think about accessibility when designing and writing web pages and apps. Experienced authors need a quick way to look up the allowed ARIA roles, states and properties for each HTML element. Browser and Assistive Technology (AT) implementers need quick access from an HTML element to its platform accessibility API.
In last week's episode, I mentioned that the HTML 5 specification now includes a media registration for
text/html. Ian Hickson explains why HTML 5 re-registers
text/html: "The main thing that needs updating is the removal of the permission for sending syntactic profiles of XML as text/html. In addition, the encoding considerations, fragment identifier definition, and the text about recognising HTML documents are somewhat out of date and can be significantly improved by referencing HTML5 now."
This addition has not been without controversy. For example, Julian Reschke believes that "RFC 2854 applies to all HTML vocabularies (and references them), while HTML5 just describes the 'current' language." [ensuing discussion] I personally disagree that HTML 5 needs to define all elements and attributes of previous HTML versions in order to "earn" the right the re-register
text/html, but it is true that HTML 5 does not do so. Or didn't, before r3683 added a definition of the
<meta scheme> attribute and a definition for the
<head profile> attribute. So there's that.
In other news:
createPattern()(methods of a
<canvas>element's drawing context) no longer throw an exception if the image isn't ready. Instead, they return
null. [Simon Pieters: drawImage() shouldn't throw INVALID_STATE_ERR]
- r3726: Add support for
aria-levelfor headings. An HTML document is an outline, as defined by its sections and headers. ARIA allows the browser to expose this outline to assistive technologies. This revision ensures that the current heading level in the outline is also exposed. [Steven Faulkner: Re: question about ARIA in HTML 5 spec text - implied use on elements not listed, although the final solution is more complicated than that because of how headers interact with nested sections]
- r3679 removes the normative reference to Unicode Technical Standard 22, which defines the method for comparing names of character encodings. If you thought character encoding itself was complicated, just wait until you try to implement character encoding aliases!
- r3717 adds another "willful violation" to HTML 5, this time of RFC 5322, which "defines a syntax for e-mail addresses that is simultaneously too strict (before the '@' character), too vague (after the '@' character), and too lax (allowing comments, white space characters, and quoted strings in manners unfamiliar to most users) to be of practical use here." [TAMURA Kent: type=email validation is too loose for practical applications]
- r3725 changes the Web Sockets API to use ports 80 (for normal traffic) and 443 (for encrypted traffic), based on a recommendation from the IANA. It had previously specified ports 81 and 815.
Interesting discussion of the week: Web Storage: apparent contradiction in spec. At issue is how much freedom browsers should have to manage their client-side state, including cookies, local databases, and local storage. On one side is Linus Upson, project manager of Google Chrome: "It is important that all local state be treated as a cache. User agents need to be free to garbage collect any local state. If they can't then attackers (or the merely lazy) will be able to fill up the user's disk." On the other side is Brady Eidson of Apple: "One key advantage of LocalStorage and Databases over cookies is that they *do* have a predictable, persistent lifetime, and the browser is *not* allowed to prune them at will. ... [O]nce the data is stored, it should be considered user data - as 'sacred' as a user's file on the file system." Linus responds: "If the spec requires UAs to maintain local storage as 'precious' it will be the first such feature in HTML 5. Everything else in the spec is treated as volatile." It goes on like that for a while. Schuyler Duveen presents some use cases. Boris Zbarsky (Mozilla) thinks it's a matter of trust. The entire thread highlights the multiple trains of thought for what local storage is for, what it means, and how it should be treated.
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
<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?
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
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.
<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
<dir> elements; r3133 and r3141 define the
<marquee> element; r3155, r3403, r3409, and r3410 define
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).
"The food here is terrible!"
"I know, and such small portions!"
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
pounds 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).
"Man didn't the right form."
"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
application/microdata+json. r3582 adds the registration information for
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."