Tuesday, October 20th, 2009
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.
This week, there were some more refinements to microdata. r4139 changes the names of the DOM properties that reflect microdata markup. r4140 renames the content property to itemValue Since no browser has actually implemented this API yet, these changes shouldn't make any difference. Standards are like sex; one mistake, and you're stuck supporting it forever! r4141 and r4147 fix up some microdata examples, in particular this example from Gavin Carothers about marking up O'Reilly's book catalog. Hooray for real-world examples!
There were also some noteworthy changes to the <video> and <audio> API. r4131 says that setting the src attribute on one of those elements should call its load() method. r4132 removes the load event for multimedia elements, and r4133 removes the "in progress" events (loadstart, loadend, and progress) that used to be fired while the video/audio file was downloading.
Other noteworthy changes this week:
- r4097 defines fallback content for the obsolete
<applet> element.
- r4098 "dramatically simplifies
<script defer> and <script async> handling." [Background: bug 7792]
- r4106 makes the step argument to the
<input> element's stepUp() and stepDown() methods optional.
- r4111 removes
<link rel=feed>. As I documented earlier this year, rel=feed was a reasonable idea that never took off. Only one browser ever implemented it, and in a survey of 3 billion pages I could only find a single page that used it.
- r4126 lists suggested default encodings for different locales. [Background: RE: HTML5 Issue 11 (encoding detection): I18N WG response...]
- r4138 drops support for non-UTF-8 encodings in Web Workers. [Background: [whatwg] Please always use utf-8 for Web Workers]
- r4099 marks the creation of Web Applications 1.0, a super-spec that contains HTML5, pre-defined microdata vocabularies, Web Workers, Web Storage, Web Database, Server-sent Events, and Web Sockets. This marks the first time that some of those specs have been published by the WHATWG, rather than the W3C, and therefore the first time that said specs have been published under a Free-Software-compatible license. (The W3C is still deciding whether to use such a license.)
Around the web:
Tune in next week for another exciting edition of "This Week in HTML5."
Posted in Weekly Review | 5 Comments »
Sunday, September 27th, 2009
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.
- r3896 tells parsers to ignore almost any end tags before the
<html> tags. There are a few special end tags which cause the parser to start constructing a new document: </html>, </head>, </body>, and oddly enough, </br>. [Related: Bug 7672]
- r3909 clarifies how user agents should parse the
type attribute of a <script> tag. The type attribute is optional; authors can simply omit it if they're embedding JavaScript.
- r3923 tweaks the algorithm for parsing the
DOCTYPE declaration. This affects DOCTYPE sniffing.
- r3967 clarifies the algorithm for ignoring the first newline or carriage return character at the beginning of a
<pre> block. [Background: [whatwg] Initial carriage return in <pre> and <textarea>]
- r3968 explains why the
<embed> element can have an infinite number of attributes. (Answer: because they are passed directly to the third-party plugin that handles the embedded content, and there are no restrictions on what kind of plugins you can have or what attributes they can take as input.)
- r3991 adds to the already-long list of legacy, non-conforming attributes that user agents may encounter in existing web content.
- r3871 and r3982 tweak the handling of Unicode surrogates. [Background: [whatwg] Surrogate pairs and character references]
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.
- 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]
- 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]
- 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
- r3905, r3948, and r3966 clarify that the
profile attribute (used by various microformats) takes a space-separated list of addresses, not just a single address. This has been the subject of heated debate for over 12 years, because HTML 4 claims that "the value of the profile attribute is a URI; user agents may use this URI in two ways..." while simultaneously claiming that "this attribute specifies the location of one or more meta data profiles, separated by white space." [Background: let's keep metadata profiles (head/@profile) in HTML for use in GRDDL etc., [whatwg] HTML4's profile="" attribute's absence in HTML5, Bug 7413, Bug 7484, Bug 7512, and Issue 55.]
- r3869 tweaks the definitions of
<section>, <article>, and <details> based on an informal study by Jeremy Keith. r3979 further tweaks the definition of <article>, and r3978 mentions that the <article> element is semantically similar to the <entry> element in RFC 4287 (Atom Syndication Format). [Background: [whatwg] article/section/details naming/definition problems. Related: Bug 7551]
- r3954 further clarifies the definition of
<footer>. [Background: Bug 7502]
- r3907 clarifies the workings of the registries for the enumerated values of
<link rel>, <meta name>, and <meta http-equiv> attributes.
- r3904 tweaks the semantics of
<link rel="up">.
- r3962 modifies the outline algorithm (used to generate a kind of "table of contents" of an HTML document based on sections and headers) to handle an obscure edge case. [Background: IRC discussion of edge case, Bug 7527, and in particular this comment on Bug 7527]
- r3987 gives an example to clarify that the
<nav> element does not always need to be a child of a <header> element.
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.)
- r3867 modifies the algorithm for sizing anamorphic video within a
<video> element, and r3913 defines how to display a frame of anamorphic video in a canvas pattern. [Background: Re: video size when aspect ratio is not 1, What The Heck Is Anamorphic?]
- r3924 defines what happens when you dynamically insert a
<source> element as a child of a <video> element that also has a src attribute, and r3925 defines what happens when you dynamically remove a <video src> attribute. [Background: Bug 7631, Bug 7632]
- r3927 gives advice on how browsers could render an
<audio> element with a controls attribute.
- r3992 makes further refinements to the
play() and pause() algorithms.
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>]
- 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]
- 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]
- 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."
Posted in Weekly Review | 1 Comment »
Wednesday, May 6th, 2009
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.
In this article:
Introducing the <hgroup> element
Topping our list of changes this week is the new <hgroup> element:
The hgroup element represents the heading of a section. The element is used to group a set of h1–h6 elements when the heading has multiple levels, such as subheadings, alternative titles, or taglines.
Meanwhile, the <header> element has been redefined:
The header element represents a group of introductory or navigational aids. A header element typically contains the section's heading (an h1–h6 element or an hgroup element), but can also contain other content, such as a table of contents, a search form, or any relevant logos.
Here is an example of how these elements can work together in marking up a specification:
<header>
<hgroup>
<h1>Scalable Vector Graphics (SVG) 1.2</h1>
<h2>W3C Working Draft 27 October 2004</h2>
</hgroup>
<dl>
<dt>This version:</dt>
<dd><a href="http://www.w3.org/TR/2004/WD-SVG12-20041027/">http://www.w3.org/TR/2004/WD-SVG12-20041027/</a></dd>
...
</dl>
</header>
Relevant background reading:
(Re)introducing the accesskey attribute
Next up in this week's changes is the reintroduction and reformulation of the accesskey attribute. In HTML 4, the accesskey attribute allows the web designer to define keyboard shortcuts for frequently-used links or form fields. In HTML 5,
All elements may have the accesskey content attribute set. The accesskey attribute's value is used by the user agent as a guide for creating a keyboard shortcut that activates or focuses the element.
If the accesskey attribute is used on a non-link, non-form-field element, it defines a command, which has a specific meaning in HTML 5.
Also new in HTML 5: the accesskey attribute may contain a number of shortcuts, space-separated, and the new .accessKeyLabel DOM property contains the shortcut key that the browser ultimately chose.
One possible enhancement, not in HTML 5 but under consideration for HTML 6, is the use of more-than-1-character strings to define roles, such as accesskey="help". The browser could then choose the appropriate shortcut key based on the user's platform and preferences.
I plan to write up a more detailed history of the accesskey attribute in a seperate article. Until then, here is some background reading:
(Re)introducing the window.setTimeout and window.setInterval functions
The window.setTimeout and window.setInterval functions have been in a state of limbo in the HTML 5 spec, waiting for an editor to take them and split them out into a separate spec. No editor has come forward, so back into HTML 5 they go.
These timer functions are complicated by their unique history in browser-land. They can take basically anything as their first argument. If you pass a function, it will be executed after the specified interval. If you pass anything else, the browser will call toString() on the parameter and then evaluate it as a JavaScript expression in the context of the current window (or, if the timer function is called from a web worker, the current WorkerUtils object). There is also a little-known but widely supported third argument to setTimeout and setInterval, which passes arguments to the evaluated expression. Meanwhile, the second argument -- the timeout value -- can also be any datatype. Browsers must call toNumber(toString(timeout)) and round down to the nearest integer.
More <video> changes
It seems that each week in HTML 5 brings more changes to the <video> element. While this is not strictly true, it is certainly true this week.
Events
Speaking of events, there was a series of event-related checkins this week. The onundo and onredo events, usually triggered by the user selecting the Undo or Redo item from the Edit menu, have been moved from the Document to the Window. [3003] These events are important for all sorts of web applications (think Google Docs and then work your imagination outward).
r3004 adds support for the onbeforeprint and onafterprint events, which are supported in Microsoft Internet Explorer since version 5.
r3005 updates the global list of event handlers to include these new events, some video-related events, some storage-related events, and several others that have slipped through the cracks during the thrashing of these features.
Other interesting changes this week
- r3019: plugins (like Flash) release the storage mutex (i.e. the
document.cookie lock mentioned in episode 28).
- r3015 adds
.protocol, .host, .hostname, .port, .pathname, .search, and .hash properties to <a> and <area> elements.
- r3032: the default size of
<h1> elements depends on how deep it is nested within nested <section> elements.
- r2988: if the document's last-modified is unknown,
document.lastModified should return the current time.
- r2981:
<time datetime="valid-datetime"></time> should display the datetime value in the user's timezone and locale.
- r3054:
<input type=tel>
Around the web
Tune in next week for another exciting episode of "This Week in HTML 5."
Posted in Weekly Review | 2 Comments »
Tuesday, March 31st, 2009
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 big news for the week of February 23rd (yes, I'm that far behind) is a collection of changes about how video is processed. The changes revolve around the resource selection algorithm to handle cases where the src attribute of a <video> element is set dynamically from script.
Background reading on the resource selection algorithm: Re: play() sometimes doesn't do anything now that load() is async, r2849: "Change the way resources are loaded for media elements to make it actually work", r2873: "make all invokations of the resource selection algorithm asynchronous."
Other video-related changes this week:
- r2845 changes the definition of the
drawImage() method of the <canvas> element to allow playing a video on a canvas.
- r2847 defines that
<video> and <audio> elements delay the document's onload event.
- r2848 changes the wording of the ready states documentation to prevent duplicate
canplay events.
- r2852 changes the wording of the ready states documentation to prevent duplicate
playing events.
- r2853 fixes the order of events of autoplayed video.
- r2855 adds an
autobuffer attribute to <audio> and <video> elements. "The autobuffer attribute provides a hint that the author expects that downloading the entire resource optimistically will be worth it, even in the absence of the autoplay attribute. In the absence of either attribute, the user agent is likely to find that waiting until the user starts playback before downloading any further content leads to a more efficient use of the network resources."
Another big change this week is the combination of r2859, 2860, and r2861: you can now declare the character encoding of XHTML documents served with the application/xhtml+xml MIME type by using the <meta charset> attribute, but only if the value is "UTF-8". Also, the charset attribute must appear in the first 512 bytes of the document. Previously, the only ways to control the character encoding of an application/xhtml+xml document were setting the charset parameter on the HTTP Content-Type header, or to use an encoding attribute in the XML prolog.
In practice, this will make no difference to encoding detection algorithms; other UTF-* encodings are detected earlier (with a Byte Order Mark), and any other encoding would require an XML prolog. This is mainly to address the desire of a few overly vocal authors to be able to serve the same markup in both text/html and application/xhtml+xml modes. Background reading: Bug 6613: Allow <meta charset="UTF-8"/> in XHTML.
Other interesting changes this week:
- r2866 makes it clear that using tables for layout is non-conforming.
- r2868 makes it clear that
<canvas> elements must have accessible fallback content within them.
- r2870 drops the
<eventsource> element.
Tune in next week for another exciting episode of "This Week in HTML 5."
Posted in Weekly Review | 1 Comment »
Wednesday, December 10th, 2008
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 big news this week is the disintegration of HTTP authentication from HTML forms (which was last week's big news). As I predicted, the proposal generated a healthy discussion, but a combination of security concerns and concerns about tight coupling ultimately did in the proposal.
In its place, r2470 includes the following conformance requirement to allow for the possibility of someone specifying such a scheme in the future (hat tip: Robert Sayre):
HTTP 401 responses that do not include a challenge recognised by the user agent must be processed as if they had no challenge, e.g. rendering the entity body as if the response had been 200 OK.
User agents may show the entity body of an HTTP 401 response even when the response do include a recognised challenge, with the option to login being included in a non-modal fashion, to enable the information provided by the server to be used by the user before authenticating. Similarly, user agents should allow the user to authenticate (in a non-modal fashion) against authentication challenges included in other responses such as HTTP 200 OK responses, effectively allowing resources to present HTTP login forms without requiring their use.
Continuing with the web forms work, the <input> element has gained a new type: a color picker, marked up as <input type=color>. Browser vendors are encouraged to integrate this field with platform-native color pickers, as appropriate. As with all new input types, browsers that do not explicitly recognize the new type will default to a simple text field.
The <audio> and <video> API continues to churn rapidly. Implementors should probably ignore it altogether until it's been stable for two consecutive weeks. To wit: r2493 removes the pixelratio attribute, originally proposed to allow authors to override the display of videos known to be encoded with incorrect an aspect ratio. r2498 adds the playing event, fired when playback as started. r2489 drops the HAVE_SOME_DATA readyState. I will try to write up a comprehensive summary of this API once its stabilizes.
Other interesting tidbits this week:
Tune in next week for another exciting episode of "This Week in HTML 5."
Posted in Weekly Review, WHATWG | 1 Comment »