This Week Day in HTML 5 – Episode 24
Welcome back to "This Week in HTML 5," where I'll try to summarize the major activity in the ongoing standards process in the WHATWG and W3C HTML Working Group. The pace of HTML 5 changes has reached a fever pitch, so I'm going to split out these episodes into daily (!) rather than weekly summaries until things calm down.
The big news for February 13, 2009 is r2814/r2815, which adds a .value property on file upload controls:
On getting, [the
.valueproperty] must return the string"C:\fakepath\"followed by the filename of the first file in the list of selected files, if any, or the empty string if the list is empty. On setting, it must throw anINVALID_ACCESS_ERRexception.
According to bug 6529, Opera already implements something close to this, and is willing to modify their implementation to match the spec text.
The other big news of the day is r2804/r2805, which defines what happens when a focused element becomes hidden.
For example, this might happen because the element is removed from its
Document, or has ahiddenattribute added. It would also happen to aninputelement when the element gets disabled.
But let's back up a step. What does it mean for an element to be "focused" in the first place? The spec has a whole section on the concept of focus. The short answer is that focus is just what you think it is: it's the element that responds when you type. As you tab around a form, the focus moves between form fields, where you can type information; as you tab around a page, the focus moves between links, which you can follow; if you tab long enough, focus moves out of the page and back to the location bar, and so forth.
The not-so-short answer that everything in the previous paragraph is platform-specific and, depending on your browser, highly customizable. The HTML 5 spec respects these platform differences, and defers the definition of what elements should be focusable to the browser, which ultimately respects the conventions of the underlying operating system.
The long answer is that virtually anything can be focusable, because HTML 5 standardizes a crucial accessibility feature that most modern browsers now implement, namely that any element can have a tabindex attribute.
It may not sound like it, but this is a really, really important feature for building accessible web applications. HTML 4 restricted the tabindex attribute to links and form fields. For reasons unknown, Internet Explorer ignored that and respected a tabindex attribute on any element. Starting with Firefox 2, Mozilla co-opted this implementation and wrote up a rough "standard" about using the tabindex attribute on anything. Once it was implemented in the browser, IBM contracted with major screenreader vendors to support Firefox's (and IE's) behavior. This provided the foundation for pure-Javascript widgets to become keyboard-accessible (also implemented by IBM). Not just theoretically, but actually, in real shipping browsers and real shipping screenreaders. Under the covers, Dojo's complex widgets are marked up with semantically meaningless <div>s and <span>s, yet they are still focusable and keyboard-navigable. The controls are in the tab order, so you can focus with the keyboard, then you can use the keyboard to further manipulate them, change their state, and so forth.
In HTML 4, there was no way to put custom controls into the tab order without breaking markup validity (unless you futzed around with custom DTDs or scripting hacks), because the tabindex attribute could only be used on links and form fields. HTML 5 "paves the cowpaths" and standardizes this definition and behavior of tabindex-on-anything. This is a huge step forward for web accessibility. The concept of focus is central to accessibility, and HTML 5 gives it the attention it deserves. (There's more to making controls accessible than just keyboard navigability, but if you don't have keyboard navigability, nothing else really matters. If you're creating your own custom Javscript widgets, you must read the (non-vendor-specific) DHTML Style Guide for implementing keyboard accessibility in custom controls.)
Now then, why is r2804 important? Well, if the element that has focus suddenly can't have focus anymore -- because it was programmatically hidden or disabled, or it was removed from the DOM altogether -- then it is vitally important to specify where the focus goes. So the HTML 5 specification lays it all out:
When an element that is focused stops being a focusable element, or stops being focused without another element being explicitly focused in its stead, the user agent should run the focusing steps for the body element, if there is one; if there is not, then the user agent should run the unfocusing steps for the affected element only.
[Background reading: Re: Lose Focus When Hidden? (SVG ISSUE-2031)]
Other interesting changes of the day:
- r2807 simplifies the definition of
window.onerror. - r2810 makes the presence of a
<noframes>element a non-ignoreable error for validators. (It was previously a "downplayed error.") - r2811 defines that "
this" in the Javascript global scope, should return aWindowProxyobject instead of aWindowobject. I confess I have no idea what that means or why it's important. Perhaps a commenter could enlighten me? - r2812 updates the way browsers should determine character encoding (using known aliases of common encodings).
- r2817 adds "transparent" to the list of colors that need to be parsed in an IE-compatible way.
- r2818 notes that putting a document in
designModedoes not actually prevent it from executing scripts.
Tune in... well, sometime soon-ish for another exciting episode of "This Week Day In HTML 5."
The WindowProxy stuff is needed for security. Most browsers implement it already, but it has never been specified before.