This Week in HTML 5 – Episode 34
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:
- r3685:
drawImage()andcreatePattern()(methods of a<canvas>element's drawing context) no longer throw an exception if the image isn't ready. Instead, they returnnull. [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.