HTML 5

Welcome back to “What’s Next in HTML,” where I’ll try to summarize the major activity in the ongoing standards process in the WHAT Working Group. With HTML5 in Last Call, the WHATWG has moved to an unversioned development model for HTML. While browser vendors are busy implementing HTML5, let’s talk about what’s next.

The big news in HTML this week is r1643. ... Well, technically that revision is over 20 months old, but there have been a flurry of updates that affect the underlying feature. What feature, you might ask? Sandboxing untrusted content.

The sandbox attribute, when specified [on an <iframe> element], enables a set of extra restrictions on any content hosted by the iframe. ... When the attribute is set, the content [hosted by the iframe] is treated as being from a unique origin, forms and scripts are disabled, links are prevented from targeting other browsing contexts, and plugins are disabled.

This could be useful for all kinds of scenarios. The HTML5 spec lists some examples of blog comments, but I think that’s mostly a red herring. Think about what’s hosted in iframes today: third-party advertising and third-party widgets. In each case, a web author wants to embed something on their page that they have little or no control over. In practice, that usually works fine. Advertising iframes don’t do anything (except display ads). Most widgets are well-behaved, and most widget frameworks (like Google Gadgets) enforce terms of service that forbid widgets from “taking over” the parent page in which they are embedded. Still, that’s a social/legal solution, not a technical one. Sandboxing is a complementary technical solution, where the parent page can actually tell the browser “Hey, I don’t fully trust this thing, but I’m embedding it anyway. Can you reduce its privileges?”

What privileges? Well, by default, “sandboxed” iframes can not

• access the DOM of the parent page (technically speaking, because the iframe is relegated to a different “origin” than the parent page)
• execute scripts
• embed their own forms, or manipulate forms via script
• read or write cookies, local storage, or local SQL databases

There are ways for the parent page to add back each of these privileges, if the third-party content needs it.

[The sandbox attribute’s] value must be an unordered set of unique space-separated tokens. The allowed values are allow-same-origin, allow-forms, and allow-scripts. The allow-same-origin keyword allows the content to be treated as being from the same origin instead of forcing it into a unique origin, and the allow-forms and allow-scripts keywords re-enable forms and scripts respectively (though scripts are still prevented from creating popups).

So it’s a security feature. You could restrict an advertising iframe to have no privileges whatsoever, but you could give a widget iframe privileges to execute its own scripts or embed its own forms.

If it’s a security feature, won’t older browsers still be insecure?

Yes. Well, no more than they are now. In fact, very few browsers support the sandbox attribute today, so we’re not just talking about users of older browsers — we’re talking about pretty much everyone. But that’s OK. The sandbox attribute is designed to be an incremental security feature. It’s an additional layer of security, not the only layer. Browsers have supported iframes for a long time, and thousands of web authors are using them despite the very real risks of embedding untrusted content. Advertising networks can and have been hacked; malicious widgets can and have been published; bad actors can and do try to do bad things to as many people as possible until they’re caught and taken down. You need to keep doing all the things you’re doing now to prevent iframe-based attacks. Then add sandbox, too.

I can’t do any filtering or sanitizing. Can I rely solely on browser-based sandboxing?

Someday, you might — might! — be able to throw out all your sanitizing code and rely solely on the sandbox attribute. Of course, you can’t do that today, because users of older browsers would still be vulnerable. So we need a “clean break” solution — a way to serve untrusted content to supporting browsers while absolutely, positively, 100% ensuring that older browsers never render the untrusted content under any circumstances. Enter the text/html-sandboxed MIME type.

All HTML pages are served with the text/html MIME type. It’s part of the HTTP headers, normally invisible to end users, but nevertheless sent by web servers every time a client requests a page. Every resource type (images, scripts, CSS files) has its own MIME type. Untrusted content could have its own MIME type. And this is where text/html-sandboxed comes in. If my web server serves up an HTML page with a MIME type of text/html, your browser will render it. If my web server serves up the same HTML page with a MIME type of text/html-sandboxed, you browser will download it (or offer to download it). Your browser doesn’t recognize that MIME type, so it falls back to the default action, which is to download it and save it as a file on your local disk. We can use this behavior to our advantage.

As browsers start supporting the sandbox attribute, they can also start supporting the text/html-sandboxed MIME type. What does it mean to “support” this new MIME type? If a user navigates directly to a page served with the new MIME type, don’t do anything special. Just download it, which is what happens already. BUT... if the user navigates to a page that includes an <iframe> element, AND the iframe has a sandbox attribute, AND the src of the iframe points to an HTML page that is served with the text/html-sandboxed MIME type, THEN render the iframe as normal (but still subject to the restrictions listed in the sandbox attribute).

Older browsers will download (or offer to download) the untrusted content. From a security perspective, that’s a good thing — at least, it means the content won’t be rendered as HTML. From a usability perspective, that’s terrible. Who wants to go to a page and suddenly have the browser offering to download a bunch of useless files? That means that you won’t really be able to use this technique until all users have upgraded to a browser that supports both the sandbox attribute and the text/html-sandboxed MIME type. That will be... a while. But it might happen someday!

Iframes suck. Can’t I just include the untrusted content inline?

There have been a number of proposals for a <sandbox> element, which you could wrap around untrusted content. All such proposals suffer fatal flaws, stemming from how today’s browsers parse HTML markup. You, the author who wants to “wrap” untrusted content, would need to ensure that the content did not “break out” of the sandbox. For instance, it could include an </sandbox> element. (Hey, it’s untrusted! That’s why we’re here in the first place.) There are a surprising number of variations of markup that are recognized as end tags (having to do with inserting whitespace characters in strange places), and you would be responsible for sanitizing all of these variations. Furthermore, you would need to ensure that the untrusted content did not include a script that called document.write(), which could be used for writing out a matching </sandbox> end tag programmatically. Think about the number of ways that script could be obfuscated, and pretty soon you’re asking individual web authors to solve the halting problem just to wrap some untrusted content.

If a wrapper element is the wrong solution, what’s the right one? This is where the “flurry of updates” has been happening. The current solution is r4619: the srcdoc attribute (with minor updates in r4623, r4624, and r4626). The best way to explain it is by example:

<iframe sandbox srcdoc="<p>Markup in an attribute, woohoo!</p>"></iframe>

Yeah, that’s pretty janky. But it has the following nice qualities:

• The “sandbox” is an attribute value, not children of a wrapper element. That means the only thing you need to escape is quotation marks.
• Legacy browsers just ignore it and render nothing at all.

It also has the following not-so-nice qualities:

• The “sandbox” is an attribute value. Markup in an attribute? Srsly? Puke.
• Legacy browsers render nothing at all.
• When you’re assembling this markup on the server side, there’s no way to know in advance whether the browser will render it or not. Except User-Agent sniffing... ick.

There is one exception to that last rule. There are a few comment systems that are entirely client-side. That is, the comments are not part of the page markup that comes down from the web server; they are programmatically added after the page is rendered. Such comment systems could use JavaScript-based feature detection to check whether the browser supported the srcdoc attribute, and write out the appropriate markup either way. I wrote the book on HTML5 feature detection. (No really! A whole fscking book!) Detecting srcdoc support would use detection technique #2:

if ("srcdoc" in document.createElement("iframe")) { ... }

But this would only help in the case where you were adding untrusted content to the page at runtime, on the client side. Server-side cases will have to wait until everybody upgrades.

So when can I use all this stuff?

Hahahahahaha. You must be new here.

No really, when?

There are several pieces here, each with their own compatibility story.

1. The sandbox attribute, for reducing privileges of untrusted content. Chromium and Google Chrome support the sandbox attribute (I tested the dev channel version 4.0.302.3); Safari, Firefox, Internet Explorer, and Opera ignore it. So you can start using the sandbox attribute today — just be sure to test in Chromium or Google Chrome to ensure you’ve set the sandbox privileges properly. It won’t have any effect in other browsers, but that’s OK. Remember, the sandbox attribute isn’t designed to be your only line of defense; it’s a complement to your existing defenses. Keep doing whatever you’re doing now (sanitizing input, auditing code, enforcing legal terms with your partners, etc), then add sandbox for extra protection.
2. The text/html-sandboxed MIME type, for ensuring that users can’t navigate to untrusted content. There are two parts to this. First, browsers must not render pages served with a text/html-sandboxed MIME type, if you navigate to the page directly. This part works in all browsers, today; they all download (or offer to download) the page markup instead of rendering it. Second, browsers that support the sandbox attribute need to render iframes served with the text/html-sandboxed MIME type (subject to the privilege restrictions listed in the sandbox attribute). No browser supports this yet, not even Google Chrome. (It renders the parent page but downloads the iframe content instead of rendering it within the frame.) So you can’t use this technique yet, until Google updates Chrome to support it. (In theory, other browser vendors will implement support for this at the same time they implement support for the sandbox attribute, but I suppose we’ll just have to wait and see.)
3. The srcdoc attribute, for including untrusted content inline. Since the fallback behavior in legacy browsers for this feature is “render nothing at all” (by design), this attribute won’t be useful until pretty much all of your visitors upgrade to browsers that support the attribute. At the moment, no current browser supports the srcdoc attribute, so it’ll be a while. If I had to guess, I’d say January 29, 2022, at 4:37pm. Plus or minus 10 years.

And now you know “What’s Next in HTML.”

Welcome to "What's Next in HTML," where I'll try to summarize the major activity in the ongoing standards process in the WHAT Working Group. Wait... what happened to This Week in HTML5? Hell, what happened to HTML5? Well, nothing. It took over five years to create, but it's in Last Call now. By all measures, it has already been wildly successful. Browser vendors are implementing it, books are being written, we have a kick-ass validator, web developers are slowly catching on, and there's still plenty of time to send us your feedback. But in the meantime, the WHAT Working Group has begun work on new, experimental features for the next version of HTML.

The next version of HTML doesn't have a name yet. In fact, it may never have a name, because the working group is switching to an unversioned development model. Various parts of the specification will be at varying degrees of stability, as noted in each section. But if all goes according to plan, there will never be One Big Cutoff that is frozen in time and dubbed "HTML6." HTML is an unbroken line stretching back almost two decades, and version numbers are a vestige of an older development model for standards that never really matched reality very well anyway. HTML5 is so last week. Let's talk about what's next.

The big news in HTML is r4439, which adds the device element. What's a <device>? I'm glad you asked.

The device element represents a device selector, to allow the user to give the page access to a device, for example a video camera.

The type attribute allows the author to specify which kind of device the page would like access to.

So it's for video conferencing, something you can currently only do with Adobe Flash or other proprietary plugins that sit on top of your browser. In fact, most of the pieces for browser-based video chat are already in place. The idea is that a device element would go hand in hand with a video element and a web socket. The device records a video stream (using the also-newly-defined Stream API) and sends the stream of video along a web socket to the other party (perhaps via an intermediate server) which renders the stream in a video element. And like the video element, the device element would be native to your browser, so browser vendors would not have to wait for third parties to add specific support for their platform.

Does all that work yet? Hell no. We don't even have a standard video codec yet! Google Chrome is the only browser that has shipped an implementation of web sockets (although it's part of WebKit, so presumably Apple could ship it in a future version of Safari if they choose). And the entire device API is still in its infancy. Nobody has even started implementing a prototype of that piece yet, and the whole idea might be scrapped by my next episode. But that's life on the bleeding edge.

And now you know "What's Next in HTML."

If you don't know what the HTML5 ruby element is, you might want to take a minute to first read the section about the ruby element in the HTML5 specification and/or the Wikipedia article on ruby characters. To quote from the HTML5 description of the ruby element:

The ruby element allows one or more spans of phrasing content to be marked with ruby annotations. Ruby annotations are short runs of text presented alongside base text, primarily used in East Asian typography as a guide for pronunciation or to include other annotations. In Japanese, this form of typography is also known as furigana.

I give a specific example further down, but for now I want to first say that the really great news about the ruby element is that last week, Google Chrome developer Roland Steiner checked in a change (r50495, and see also related bug 28420) that adds ruby support to the trunk of the WebKit source repository, thus making the ruby feature available in WebKit nightlies and Chrome dev-channel releases.

A simple example

The following is a simple example of what you can do with the ruby element; make sure to view it in a recent WebKit nightly or Chrome dev-channel release. Note that the text is an excerpt from the source of a ruby-annotated online copy of the short story Run, Melos, Run by the writer Osamu Dazai, which I came across by way of Piro's info page for his XHTML Ruby add-on for Firefox (and which I mention a bit more about further below).

きのうの豪雨で山の水源地は<ruby>氾濫<rp>（</rp>
<rt>はんらん</rt><rp>）</rp></ruby>し、濁流
<ruby>滔々<rp>（</rp><rt>とうとう</rt><rp>）</rp>
</ruby>と下流に 集り、猛勢一挙に橋を破壊し、どうどうと 
響きをあげる激流が、<ruby>木葉微塵<rp>（</rp>
<rt>こっぱみじん</rt><rp>）</rp></ruby>に<ruby>橋桁
<rp>（</rp><rt>はしげた</rt><rp>）</rp></ruby>
を跳ね飛ばしていた。

If you don't happen to have Japanese fonts installed, here's a screenshot of the source for reference:

Notice that the actual annotative ruby text (which I've highlighted in yellow in the source just for the sake of emphasis) is marked up using the rt element as a child of the ruby element, and the text being annotated is the node that's a previous sibling to that rt content as a child of the ruby element. The final new element in the mix is the rp element, which is simply a way to mark up the annotative ruby text with parenthesis, for graceful fallback in browsers that don't support ruby.

So here's the rendered view of that same text:

見よ、前方の川を。きのうの豪雨で山の水源地は氾濫（はんらん）し、濁流滔々（とうとう）と下流に集り、猛勢一挙に橋を破壊し、どうどうと響きをあげる激流が、木葉微塵（こっぱみじん）に橋桁（はしげた）を跳ね飛ばしていた。

And here is a screenshot of how it should look in a recent WebKit nightly or Chrome dev-channel release:

Notice that the annotative ruby text is displayed above the ruby base it annotates. If you instead view this page in a browser that doesn't support the ruby feature, you'll see that the ruby text is just shown inline, in parenthesis following the ruby base it annotates. So the feature falls back gracefully in older browsers.

Support in other browsers

Current versions of Microsoft Internet Explorer also have native support for ruby, and you can also get ruby support in Firefox by installing Piro's XHTML Ruby add-on (and for more details, see his XHTML ruby add-on info page) — so we are well on the way to seeing the HTML5 ruby feature supported across a range of browsers. If you're not accustomed to reading printed books and magazines and such in Japanese, that might not sound like such a big deal. But for authors and developers and content providers in Japan who want to finally be able to use on the Web this very common feature of Japanese page layout from the print world, getting ruby support into another major browser engine is a huge win, and something to be very excited about.

For a brief period today, there were no outstanding e-mails or bugs on the specs, and so I took that opportunity to transition us here at the WHATWG to the next stage of HTML5's development: Last Call! This affects three specs at the WHATWG:

• HTML5
• Web Workers
• Microdata vocabularies

There's also a version of the spec called Web Applications 1.0 (for nostalgic reasons) that has all of the above as well as a number of other specs, namely Web Storage, Web Database, Server-sent Events, and the Web Sockets API and protocol, all together in one document. With the exception of the Web Database spec, they're all now in last call at the WHATWG.

So if you've been waiting to see if someone else would report the problem that you had seen, well, if it's not fixed, they didn't! So you should now send that feedback in yourself.

There's two ways to send feedback. If your feedback is something short and simple, you can just load up the spec in your browser, click on the section with the problem, then type in your message using the review comments box that appears at the bottom of the window, and hit the "Submit Review Comments" button. This works for the HTML5 and Web Applications 1.0 specs. (Thanks to the W3C HTML Working Group for making their bug database available to us for this purpose.)

If your feedback is more elaborate, then you should subscribe to the mailing list and then send your feedback there.

Note: Lest there be any confusion, the W3C HTML WG has not yet transitioned HTML5 to Last Call at the W3C. HTML5 is a joint effort of W3C and WHATWG groups, but we have different issues lists and different criteria for going to Last Call. For more details on the W3C HTML WG's processes, see the W3C HTML WG charter.

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:

• An Introduction to HTML5 covers a lot of ground
• Video on the Web is the latest chapter from my upcoming book on HTML5.

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

The big news this week is microdata. Google sponsored a usability study on microdata syntax, which resulted in significant changes to the spec [r4066]. Also related: r4067 fixes a microdata example, r4068 updates the algorithm for extracting RDF triples from microdata, r4069 does some spec cleanup, and r4070 splits out the predefined microdata syntaxes into their own specs:

• Microdata vocabularies: vCard
• Microdata vocabularies: vEvent
• Microdata vocabularies: Licensing Works

There was also work on events this week. r4032 defines what events are involved in copy and paste, closing bug 7668. r4037 defines when the reset event fires, closing bug 7699. r4039 defines when the abort event fires, closing bug 7700.

This week brings another milestone, one which went mostly unremarked in mailing lists, blogs, and IRC chatter. As with any large project, Ian Hickson has maintained an informal wishlist of things he would like to clarify, define, or otherwise include in HTML5. The list has grown and shrunk over the years. The list was stored in HTML comments, so it has never been visible unless you viewed the source of the HTML5 specification itself. And as with any large project, there comes a time when you realize you're not going to get to everything on your wishlist.

This week, the wishlist shrunk a lot, as Ian finally "punted" on several issues. Some of them may be tackled in HTML6. (Of course, if someone feels strongly enough, they can certainly argue that an issue still needs to be tackled in HTML5.) r4023 shows the deletions from the wishlist, including: "ability for a web app to save a file to the local disk," proposals for new attributes on the <title> element, partial form validation, multi-column select widgets, auto-formatting of number fields (like many spreadsheet programs do), relative dates, input controls for repeating dates (like anniversaries or other repeating events), and input controls for currency.

Other noteworthy changes this week:

• r4011 syncs with the latest Origin spec, closing bug 7599.
• r4031 allows user agents to explicitly disable <canvas> support.
• r4042 limits PUT and DELETE actions on web forms to the same origin as the page. This is similar to the restriction on XMLHttpRequest.
• r4057 defines <applet>.
• r4076 disallows the backtick (`) character in unquoted attribute values, because Internet Explorer will treat it as an attribute value delimiter.
• r4082 adds the document.head property, which makes me very happy.
• r4083 states that an <audio> element without controls should always be hidden. (You can still make a visible <audio> element; just give it a controls attribute.)
• r4086 tries to clarify the ever-elusive WindowProxy object.
• r4091 registers the various HTTP headers that are used in the new features of HTML5, including Ping-From and Ping-To.
• r4092 and r4094 add a non-normative index of HTML elements and attributes. Think of it as an "HTML5 cheat sheet." Various third parties have attempted such a list, but none have been able to keep up with the maintenance required as HTML5 evolved.

Around the web:

• Sniffing for RSS 1.0 feeds served as text/html, my original research into how browsers treat mis-labeled RSS feeds. My proposal was accepted and incorporated into the latest draft of the Content Sniffing spec.
• mimesniff, my implementation of the Content Sniffing draft spec. Requires Python 3.1 or later.
• SVG at Google and in Internet Explorer, by my friend and colleague Brad Neuberg (the mastermind behind SVGWeb).
• A cute animated cartoon about HTML5 and <canvas>, using HTML5 and <canvas>.
• I will be speaking on HTML5 at two upcoming Google Developer Days. The first is in Prague on November 6; the second is in Moscow on November 10.

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

Over the past few weeks, Google has been preparing and then running a usability study to test the microdata feature of HTML5.

Methodology

We first created three different variants based on the original microdata proposal:

1. One based on what the spec said (documentation)
2. One trying to put types in an explicit itemtype="" attribute and moving "about" to item="", and replacing itemfor="" with just having multiple item=""s with the same name (documentation)
3. One trying to remove types altogether and using item as a boolean attribute. (documentation)

Our plan was to run six studies, two for each variant, with each participant running through the following steps:

1. Read and comment on a couple of motivating slides explaining why one would care about microdata
2. Read the provided documentation for the variant being tested
3. Look at and comment on the animals example with microdata (variant 2, variant 3)
4. Exercise: try to extract the data from the "flickr" example (variant 2, variant 3)
5. Exercise: try to annotate the blog example (variant 2, variant 3)
6. Exercise: try to annotate the review example (variant 2, variant 3)
7. Compare and contrast the "yelp" example with microdata to the equivalent of one of the other two variants (variant 2, variant 3)

We made some changes along the way. After the first three, it became clear that "about" was a very confusing term to use for giving the item's global identifier, and so we changed the documentation and examples to use "itemid" instead (which turned out to be much less confusing). Early on we also introduced some documentation text to explain the differences between the variants in the last exercise, because just showing them the two side by side wasn't getting us anything useful (1 to 3, 2 to 1, 2 to 3, 3 to 1).

After our sixth participant canceled on us, we decided to create a fourth variant (documentation) based on what we'd learnt with the first five, and to get two more participants to test this variant specifically. For these participants, we used the following methodology:

1. Read and comment on a couple of motivating slides explaining why one would care about microdata
2. Read the provided documentation for the variant being tested
3. Look at and comment on the animals example with microdata
4. Exercise: try to extract the data from the "flickr" example
5. Exercise: try to extract the data from the review example
6. Exercise: try to annotate the blog example
7. Exercise: try to annotate the "yelp" example

Conclusions

Some interesting things came out of this study. First, as mentioned above, the term "about" turns out to be highly non-intuitive. I originally took the word from RDFa, on the principle that they knew more about this than I did, but our participants had a lot of trouble with that term. When we changed it to "itemid", there was a marked improvement in people's understanding of the concept.

Second, people were much less confused about types than I thought they would be. In preparing for this study I discussed microdata with a number of people, and I found that one major area of confusion was the concept of types vs the concept of properties. This is why variant 3 has no types: I wanted to find out whether people had trouble with them or not. Well, not only did people not have problems with types, several participants went out of their way to specify the type of an item, for example using the attribute name "type" instead of "item" in variant 1.

It seems that while reasoning about types at the theoretical level is somewhat confusing, it isn't so confusing that the concept should be kept out of the language. Instead, types should just be more explicitly mentioned. This is why we renamed "item" to "itemtype".

Third, people were confused by the scoping nature of the "item" attribute. Some of our participants never understood scoping at all, and most of the participants who understood the concept were still quite confused by the "item" attribute. We were encouraged, however, by one variant 1 participant's sudden enlightenment when they saw variant 3's "itemscope" attribute, and by the reaction of the variant 3 participant to the "itemscope" attribute compared to the reactions that the other two variants' participants had to their "item" attributes. This is why we split "item" into "itemtype" and "itemscope", instead of just using "itemtype".

We found that people who understood microdata's basic features also understood "itemfor", but while we were doing the study, it was pointed out on the WHATWG list that "itemfor" makes it impossible to find the properties of an item without scanning the whole document. This is why we tested the <itemref> idea in variant 4. People were at least as able to understand this as "itemfor".

In general, the changes we made for variant 4 were all quite successful. With one exception, that's what HTML5 now says. The one exception is that I hoisted the "itemid" property to an attribute like "itemtype", based on the argument that if people want to scan a document for the item with a particular "itemid", <itemref> would make it impossible to do it for the property without creating the microdata graph for the entire page.

One thing we weren't trying to test but which I was happy to see is that people really don't have any problems dealing with URLs as property names. In fact, they didn't even complain about URLs being long, which reassured me that microdata's lack of URL shortening mechanisms is probably not an issue.

Overall, this was a good and useful experience. I hope we can use usability studies to test other parts of HTML5 in the future.

Update

(Added based on Twitter feedback.) Some people have asked to see the raw data we collected in this study. I've uploaded the raw files as they were at the end of each participant's one-hour session. This data on its own isn't especially useful; what matters is how the participants reached their conclusions. There are seven hours' worth of video to document that, but we can't publish the video online, since that would be a violation of the legal agreement we have with the participants to protect their privacy.

The study was conducted by one of Google's usability study moderators, and the participants were screened and recruited by a separate team of usability study recruiters specifically for this study. Our criteria were intended to find Web developers who were somewhat comfortable with HTML and who had at most a passing knowledge of the HTML5 effort.

Bear in mind, when looking at the raw data, that the participants had just one hour to go from not knowing about this at all, to being expected to read and write code in a new syntax, with no hints other than the examples and the documentation (which most only glanced at!).

I recently found myself testing how browsers sniff for RSS 1.0 feeds that are served with an incorrect MIME type. (Yes, my life is full of delicious irony.) I thought I'd share my findings so far.

Firefox

Firefox's feed sniffing algorithm is located in nsFeedSniffer.cpp. As you can see, starting at line 353, it takes the first 512 bytes of the page, looks for a root tag called rss (for RSS 2.0), atom (for Atom 0.3 and 1.0), or rdf:RDF (for RSS 1.0). The RSS 1.0 marker is really a generic RDF marker, so it then does some additional checks for the two required namespaces of an RSS 1.0 feed, http://www.w3.org/1999/02/22-rdf-syntax-ns# and http://purl.org/rss/1.0/. This check is quite simple; it literally just checks for the presence of both strings, not caring whether they are the value of an xmlns attribute (or indeed any attribute at all).

Firefox has an additional feature which tripped up my testing until I understood it. IE and Safari both have a mode where they essentially say "I detected this page as a feed and tried to parse it, but I failed, so now I'm giving up, and here's an error message describing why I gave up." Firefox does not have a mode like this. As far as I can tell, if it decides that a resource is a feed but then fails to parse the resource as a feed, it reparses the resource with feed handling disabled. So an non-well-formed feed served as application/rss+xml will actually trigger a "Do you want to download this file" dialog, because Firefox tried to parse it as a feed, failed, then reparsed it as some-random-media-type-that-I-don't-handle. A non-well-formed feed served as text/html will actually render as HTML, but only after Firefox silently tries (and fails) to parse it as a feed.

There's nothing wrong with this approach; in fact, it seems much more end-user-friendly than throwing up an incomprehensible error message. I just mention it because it tripped me up while testing.

Internet Explorer

Internet Explorer's feed sniffing algorithm is documented by the Windows RSS team. About RSS 1.0, it states:

IE7 detects a RSS 1.0 feed using the content types application/xml or text/xml. ... The document is checked for the strings <rdf:RDF, http://www.w3.org/1999/02/22-rdf-syntax-ns# and http://purl.org/rss/1.0/. IE7 detects that it is a feed if all three strings are found within the first 512 bytes of the document. ... IE7 also supports other generic Content-Types by checking the document for specific Atom and RSS strings.

Now that I understand IE's algorithm, I have to concede that this documentation is 100% accurate. However, it doesn't tell the full story. Here's what actually happens. If the Content-Type is

• application/xml
• text/xml
• application/octet-stream
• text/plain
• text/html
• the empty string, or
• missing altogether

...then IE will trigger its feed sniffing. Once IE triggers its feed sniffing, it will never change its mind (unlike Firefox). If feed parsing fails, IE will throw up an error message complaining of feed coding errors or an unsupported feed format. The presence or absence of a charset parameter in the Content-Type header made absolutely no difference in any of the cases I tested.

And how exactly does IE detect an RSS 1.0 feed, once it decides to sniff? The documentation on MSDN is literally true: "The document is checked for the strings <rdf:RDF, http://www.w3.org/1999/02/22-rdf-syntax-ns# and http://purl.org/rss/1.0/. IE7 detects that it is a feed if all three strings are found within the first 512 bytes of the document." Combined with our knowledge of which Content-Types IE considers "generic," we can conclude that the following page, served as text/html, will be treated as a feed in IE:

<!-- <rdf:RDF -->
<!-- http://www.w3.org/1999/02/22-rdf-syntax-ns# -->
<!-- http://purl.org/rss/1.0/ -->
<script>alert('Hi!');</script>

[live demonstration]

Why Bother?

I am working with Adam Barth and Ian Hickson to update draft-abarth-mime-sniff-01 (the content sniffing algorithm referenced by HTML5) to sniff RSS 1.0 feeds served as text/html. It is unlikely that we will adopt IE's algorithm, since it seems unnecessarily pathological. I am proposing the following change, which would bring the content sniffing specification in line with Firefox's sniffing algorithm:

In the "Feed or HTML" section, insert the following steps between step 10 and step 11:

10a. Initialize /RDF flag/ to 0.

10b. Initialize /RSS flag/ to 0.

10c. If the bytes with positions pos to pos+23 in s are exactly equal to 0x68, 0x74, 0x74, 0x70, 0x3A, 0x2F, 0x2F, 0x70, 0x75, 0x72, 0x6C, 0x2E, 0x6F, 0x72, 0x67, 0x2F, 0x72, 0x73, 0x73, 0x2F, 0x31, 0x2E, 0x30, 0x2F respectively (ASCII for "http://purl.org/rss/1.0/"), then:

1. Increase pos by 23.
2. Set /RSS flag/ to 1.

10d. If the bytes with positions pos to pos+42 in s are exactly equal to 0x68, 0x74, 0x74, 0x70, 0x3A, 0x2F, 0x2F, 0x77, 0x77, 0x77, 0x2E, 0x77, 0x33, 0x2E, 0x6F, 0x72, 0x67, 0x2F, 0x31, 0x39, 0x39, 0x39, 0x2F, 0x30, 0x32, 0x2F, 0x32, 0x32, 0x2D, 0x72, 0x64, 0x66, 0x2D, 0x73, 0x79, 0x6E, 0x74, 0x61, 0x78, 0x2D, 0x6E, 0x73, 0x23 respectively (ASCII for "http://www.w3.org/1999/02/22-rdf-syntax-ns#"), then:

1. Increase pos by 42.
2. Set /RDF flag/ to 1.

10e. Increase pos by 1.

10f. If /RDF flag/ is 1, and /RSS flag/ is 1, then the /sniffed type/ of the resource is "application/rss+xml". Abort these steps.

10g. If pos points beyond the end of the byte stream s, then continue to step 11 of this algorithm.

10h. Jump back to step 10c of this algorithm.

Further Reading

You can see the results of my research to date and test the feeds for yourself. Because my research results are plain text with embedded HTML tags, I have added 512 bytes of leading whitespace to the page to foil browsers' plain-text-or-HTML content sniffing. Mmmm -- delicious, delicious irony.

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.

• r3875 states that setting document.domain should release the storage mutex. (The storage mutex is a global lock that is acquired when setting cookies and released immediately afterwards. Since cookies are domain-specific, changing the domain dynamically like this needs to release the lock in case the page wants to update the cookies on the new domain.) [Background: [whatwg] Storage mutex and cookies can lead to browser deadlock, [whatwg] RFC: Alternatives to storage mutex for cookies and localStorage, [whatwg] Application defined "locks"]
• r3878 states that setting document.domain makes Web Storage unusable, to avoid deadlocks with Web Storage's own locking mechanism. [Background: [whatwg] localStorage, the storage mutex, document.domain, and workers]
• r3879 warns against setting document.domain on web applications that are hosted on shared servers. The spec explains the problem: "If an untrusted third party is able to host an HTTP server at the same IP address but on a different port, then the same-origin protection that normally protects two different sites on the same host will fail, as the ports are ignored when comparing origins after the document.domain attribute has been used."

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.

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>]
• 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

• I like this proposal for adding a document.head property. It would presumably be faster than document.getElementsByTagName('head')[0], and more reliable than document.documentElement.firstChild.
• Character encoding on the web is even worse than you think.
• Re: On testing HTML

Around the Web

• Brad Neuberg: A video introduction to HTML5
• Google (my employer) released an intriguing project called Google Chrome Frame. It's a plugin for Internet Explorer that enables a number of new HTML5 capabilities on an opt-in basis. Here's a few technical details. Reaction has ranged from impressed to unimpressed to positively ironic. Google Wave is one of the first web applications to opt-in and suggest that Internet Explorer users download the plugin.
• Steve Faulkner: HTML5 & WAI-ARIA: Happy Families, a slide deck about current HTML5 accessibility features, misfeatures, and support in browsers and assistive technologies.
• Burst Engine is "an OpenSource vector animation engine for the HTML5 Canvas Element."
• Peter-Paul Koch: The HTML5 drag and drop disaster

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

On August 7, 2009, Adrian Bateman did what no man or woman had ever done before: he gave substantive feedback on the current editor's draft of HTML5 on behalf of Microsoft. His feedback was detailed and well-reasoned, and it spawned much discussion. See also: Adrian's followup on <progress> (and more here); his followup on <canvas>; on <datagrid> (which was actually dropped from HTML5 just minutes after Adrian posted his initial feedback, for unrelated reasons); his discussion with a Mozilla developer about <bb> (which was also subsequently dropped); discussion about <dialog> (which has now been dropped -- more on that in just a minute); Adrian's followup on <keygen>, with additional concerns listed here; his followup on the new input types; and last but not least, his position on <video> and <audio> (and followup about best-choice algorithms).

As you might expect, much of the discussion since August 7 has been driven by Microsoft's feedback. After five years of virtual silence, nobody wants to miss the opportunity to engage with a representative of the world's still-dominant browser. I want to focus on two discussions that have led to recent spec changes.

The rise and fall of <keygen>

The <keygen> element was invented by Netscape and subsequently reverse-engineered by every other browser vendor except Microsoft. It had never been part of any HTML specification before; indeed, it wasn't well-documented anywhere. It was added to HTML5 earlier this year (and covered in episode 12 and episode 31). The spec text borrows heavily from this incredibly detailed documentation posted to the WHATWG mailing list last July.

Adrian, on behalf of Microsoft, has stated in no uncertain terms that Microsoft has no intention of ever implementing the <keygen> element, and they would like it to be removed from HTML5. But what does "implementing" <keygen> mean? Well, the point of <keygen> is to provide a cryptography API, but as Ian Hickson points out, the element itself "integrates tightly with the form submission model, it affects the DOM APIs of other elements, it affects the parser, it affects the form control validity model -- it's not a feature that can be sensibly considered 'optional' if our goal is cross-browser interoperability. However, there is an alternative that I think would still satisfy Microsoft's desires to not implement <keygen>'s cryptographic features while still bringing interoperability to the platform in every other respect: we could make the support of each individual signature algorithm optional."

r3843 does just that -- it makes the cryptography parts of <keygen> optional. It is important that the element itself be implemented (even without the crypto bits), because it interacts with the DOM and the parsing model in strange ways.

As an postscript of sorts, I should point out that a recent change to the keytype attribute (r3868) allows client-side script to detect whether the crypto bits are actually supported. Detecting features is important, and this subtle change will allow authors to write feature detection scripts instead of relying on browser sniffing to decide whether to use keygen-based cryptography.

The art of conversation is, like, dead and stuff

Another hot topic this week is the removal of the <dialog> element. As I mentioned at the beginning of this article, Microsoft questioned the wisdom of a specialized element for marking up dialog. Other people have suggested that the element does not actually go far enough -- it lets you mark up basic conversation (people talking), but provides no semantics for stage directions, actions, thoughts, voiceover narration, and so on. (See also: Unwebbable, "The screenplay problem.")

To decide this burning question, the <dialog> element was removed, and conversations are now listed in the section on Common idioms without dedicated elements, with an example of how one might mark up a conversation with more generic markup, if one were inclined to do so. Predictably, this has already caused some backlash from the pro-<dialog> camp.

The conversation about marking up conversations also intersects with another burning question: can you use the <cite> element to mark up a person's name? HTML 4 said yes, and even provided an example that used the <cite> element that way. Dan Connolly, who added the <cite> element to HTML 2 (yes, 2), says "I consider that a bug in the HTML 4 spec. I wish I had reviewed it more closely." Still, specs are normative, not what their authors say about them after-the-fact, and the web has collectively had 12 years of HTML 4 which explicitly blessed the technique. I've used <cite> to mark up people's names for years in my own markup, and I'm certainly not going to go back and change all those blog entries to conform to somebody's sense of purity.

New examples

Speaking of examples, the HTML5 spec just got a whole lot more of them. To wit:

• r3784: <html> example
• r3785: <head> example
• r3786: <base> example
• r3787: <link> example
• r3789: <meta> example
• r3790: <style> example
• r3791: <script> example
• r3793 and r3856: <noscript> example
• r3796: <article> example
• r3808: <iframe> example
• r3809: <embed> example
• r3810: <canvas> example
• r3811: <math> example
• r3814: <form> and <fieldset> examples
• r3815: list="" example
• r3816: readonly="" example
• r3817: required="" example
• r3818: multiple="" example
• r3819: maxlength="" example
• r3820: step, min, and max examples
• r3821: <button> example
• r3822: <select> example
• r3823: <optgroup> example
• r3824: <textarea> and <output> examples
• r3825: <details> example
• r3801 and r3806: <h1> example
• r3804: <hr> and <span> examples
• r3805: <del> example
• r3863: example of how to get the filename out of input.value
• r3799: example of how to mark up comments on a weblog using <article>, <section>, and <header>

Further Reading

Other spec changes this week:

• r3852 allows <span title=&>
• r3846 clarifies that <button type="reset"> is excluded from form validation.
• r3841 clarifies that <aside> may be used for sidebars, advertising, or groups of <nav> elements. It can still be used for pull quotes, for example the sentence "Everything you thought you knew about strings is wrong" on a page about string processing.
• r3837 defines the concept of "being rendered." As with many things in HTML5, what scares me most about this change is that we survived so long without this being defined at all.
• r3853 adds a note about another willful violation, this time stripping the Byte Order Mark character (U+FEFF) even from places where it is not being used as a byte order mark.

Around the web:

• Francisco Ryan Tolmasky: On HTML 5 Drag and Drop.
• Jamie Newman: How to Draw with HTML 5 Canvas
• WHATWG wiki: Differences between HTML and XHTML is chock full of interesting comparisons.
• WHATWG wiki: Web Encodings, "an attempt at fixing the Web encoding problem." Good luck with that.
• Edward O'Connor: Blog templates: a case study in using HTML5’s sectioning elements. "The HTML5 spec introduces several new sectioning elements. ... There's widespread confusion about when to use these elements." No kidding.
• Mark Pilgrim: Detecting HTML5 Features. I'm currently writing a book on HTML5, to be published next February by O'Reilly and Google Press. This is the second chapter I've written so far. (The first chapter I wrote was Let's Call It a Draw(ing Surface), a still-unfinished tutorial on using the canvas API.)
• Aten Design Group: A Brief History of HTML.
• Jeremy Keith: The devil in the details, on the continuing saga of marking up conversations.
• Edward O'Connor: HTML5: normativity & authoring guides. "Not only is [HTML5] big, but it's full of complicated algorithms and other browser implementation details that even standards-aware web authors probably don't care about." Indeed.
• Sam Ruby: First Polyglot Validator Check Deployed. I personally believe this is a waste of time, since there are approximately 3 people in the world who actually serve polyglot documents, all of whom seem to be doing fine without this option, and the presence of the option will just serve to confuse the other 3 million validator users who think they're serving XHTML when they're not. But one of those 3 people has commit access to the HTML5 validator, so I guess we'll get to see whether I'm right or wrong.

Quote of the week:

Richard Schwerdtfeger, Distinguished Engineer and Chief Accessibility Architect at IBM, co-author of Accessible Rich Internet Applications (WAI-ARIA) 1.0, XHTML Access Module, and XHTML Role Attribute Module, in a discussion of aria-describedby:

longdesc was a disaster.

On a personal note, I'm writing this on a new laptop with a sticky "3" key, a minor annoyance turned major by the fact that this week's revisions are numbered in the 3000 range. While many people complain about the pace of changes in HTML5, as far as I'm concerned, revision 4000 can not come quickly enough.

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