This Week in HTML5 – Episode 36

Since I started publishing these weekly summaries over a year ago, I've watched the HTML5 specification grow up. In episode 1, the big news of the week was the birth of an entirely new specification (Web Workers). Slowly, steadily, and sometimes painstakingly, the HTML5 specification has matured to the point where the hottest topic last week was the removal of a little-used element ( <dialog> ) and the struggle to find a suitable replacement for marking up conversations.

This week's changes are mundane, and I expect (and hope!) that future summaries will be even more mundane. That's a good thing; it tells me that, as implementors continue implementing and authors continue authoring, there are no show-stoppers and fewer and fewer "gotchas" to trip them up. Thus, the overarching theme this week -- and I use the term "theme" very loosely -- is "the never-ending struggle to get the details right."

Parsing

HTML5 is full of algorithms. Most of them are small parts of one mega-algorithm, called Parsing HTML Documents. Contrary to popular belief, the HTML parsing algorithm is deterministic: for any sequence of bytes, there is one (and only one) "correct" way to interpret it as HTML. Notice I said "any sequence of bytes," not just "any sequence of bytes that conforms to a specific DTD or schema." This is intentional; HTML5 not only defines what constitutes "valid" HTML markup (for the benefit of conformance checkers), it also defines how to parse "invalid" markup (for the benefit of browsers and other HTML consumers that take existing web content as input). And sweet honey on a stick, there sure is a lot of invalid markup out there.

Accessibility

As with so many things in the accessibility world, all of this week's changes revolve around the thorny problem of focus. I previously explained why focus is so important in episode 24.

r3887 specifies that each <area> in a client-side image map should be focusable.

in a client-side image map should be focusable. r3919 encourages browser vendors to expose tooltips to keyboard-only users. For example, in Firefox 3.5, if you hover your cursor over a hyperlink that defines a title attribute, you will see the title attribute as a tooltip. But if you tab to the same link with the keyboard, no tooltip appears. Now imagine that you're physically unable to use a mouse, and you begin to see the problem. [Background: Bug 7362 and Issue 80]

attribute, you will see the attribute as a tooltip. But if you tab to the same link with the keyboard, no tooltip appears. Now imagine that you're physically unable to use a mouse, and you begin to see the problem. [Background: Bug 7362 and Issue 80] r3928 defines an intriguing proposal about canvas accessibility, which probably deserves its own article. Here's the short version: you can already define "fallback content" within a <canvas> element that is shown to browsers that don't support the canvas API . This change dictates that the "fallback content" should remain keyboard-focusable even in browsers that do support the canvas API . To quote the spec: "This allows authors to make an interactive canvas keyboard-focusable: authors should have a one-to-one mapping of interactive regions to focusable elements in the fallback content." This is a draft proposal; as far as I know, no browser actually supports it yet, and it may get reverted in the future. [Background: Bug 7404]

element that is shown to browsers that don't support the canvas . This change dictates that the "fallback content" should remain keyboard-focusable even in browsers that do support the canvas . To quote the spec: "This allows authors to make an interactive canvas keyboard-focusable: authors should have a one-to-one mapping of interactive regions to focusable elements in the fallback content." This is a draft proposal; as far as I know, no browser actually supports it yet, and it may get reverted in the future. [Background: Bug 7404] r3969 clarifies that browsers must do nothing when the user activates a label whose corresponding input control is hidden (in any manner, including a display: none CSS rule). [Background: Bug 7583]

Security

All of this week's security-related changes revolve around document.domain . As you might expect from its name, this property returns the domain name of the current document. Unfortunately (for security), the property is not read-only; you can also set document.domain to pretty much anything. This can cause all sorts of horrible side effects, since so many things (cookies, local storage, same-origin restrictions on XMLHttpRequest ) rely on the domain of the document. This set of changes attempts to reduce the nasty side effects (and the possible attack surface) in case you absolutely must set document.domain to something other than its default calcuated value.

Semantics

Video

As regular readers of this column are aware, one of the big new user-visible features of HTML5 is native video support without plugins. As video is incredibly complicated, so to is the video support in HTML5. (Although not related to this week's changes, you may be interested to read my series, A gentle introduction to video encoding.)

Web Forms

Forms continue to be difficult.

r3874 allows browsers to reset the list of selected files of an <input type="file"> element by setting its value attribute to the empty string. [Background: [whatwg] Setting .value on <input type=file>]

element by setting its attribute to the empty string. [Background: [whatwg] Setting .value on <input type=file>] r3922 clarifies that setting the disabled attribute of a <fieldset> element should not disable the children of the fieldset's <legend> element. [Background: Bug 7591]

attribute of a element should not disable the children of the fieldset's element. [Background: Bug 7591] r3934 defines that the maxLength property should return -1 on a <textarea> or <input> element that does not include a maxlength attribute. [Background: Bug 7427]

property should return -1 on a or element that does not include a attribute. [Background: Bug 7427] r3957 clarifies that implicit form submission should validate the form first. [Background: Bug 7511]

Interesting Discussion Threads This Week

Around the Web

Tune in next week for another exciting edition of "This Week in HTML5."