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."

• 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."

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."

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."

This big news this week is the <datagrid> element. This is a brand spanking new element introduced in r2962.

In the datagrid data model, data is structured as a set of rows representing a tree, each row being split into a number of columns. The columns are always present in the data model, although individual columns might be hidden in the presentation.

Each row can have child rows. Child rows may be hidden or shown, by closing or opening (respectively) the parent row.

Rows are referred to by the path along the tree that one would take to reach the row, using zero-based indices. Thus, the first row of a list is row "0", the second row is row "1"; the first child row of the first row is row "0,0", the second child row of the first row is row "0,1"; the fourth child of the seventh child of the third child of the tenth row is "9,2,6,3", etc.

The chains of numbers that give a row's path, or identifier, are represented by arrays of positions, represented in IDL by the RowID interface.

The root of the tree is represented by an empty array.

Each column has a string that is used to identify it in the API, a label that is shown to users interacting with the column, a type, and optionally an icon.

The possible types are as follows:

Keyword	Description
text	Simple text.
editable	Editable text.
checkable	Text with a check box.
list	A list of values that the user can switch between.
progress	A progress bar.
meter	A gauge.
custom	A canvas onto which arbitrary content can be drawn.

Each column can be flagged as sortable, in which case the user will be able to sort the view using that column.

Columns are not necessarily visible. A column can be created invisible by default. The user can select which columns are to be shown.

When no columns have been added to the datagrid, a column with no name, whose identifier is the empty string, whose type is text, and which is not sortable, is implied. This column is removed if any explicit columns are declared.

Each cell uses the type given for its column, so all cells in a column present the same type of information.

The other major change to the spec this week is the <keygen> element. As I mentioned in episode 12, someone went to the trouble of documenting the <keygen> element, and there has been a surprising amount of discussion about it in the past six months. Simply put, the keygen element represents a key-pair generator control. You include it in a <form>. When your browser submits the form, the private key is stored in the local keystore, and the public key is packaged and sent to the server. [r2960]

Not much else went into the spec this week, but there's been a lot of interesting activity around the web.

• A new W3C Working Draft of HTML 5 is out. As I've mentioned before, this is just a snapshot of progress-to-date. By its very nature, it is out of date as soon as it's published, since the working group continues to progress while the webmaster gnomes are publishing.
• Also published: the latest draft of "HTML 5 differences from HTML 4", compiled by Opera's Anne van Kesteren.
• Mozilla bug 465007: "Harmonize content sniffing in HTML 5 and Firefox." The next version of Firefox will sniff images the way the HTML 5 specification recommends. I am still opposed to content sniffing on philosophical grounds, but philosophy doesn't get you very far on the open web, and documented heuristics are better than undocumented heuristics. And interoperable, documented heuristics are even better!
• Speaking of content sniffing, Adam Barth's [PDF] whitepaper, Secure Content Sniffing For Web Browsers, is an excellent read.
• Henri Sivonen's The Last of the Parsing Quirks is equally fascinating.
• Superset encodings [Re: ISO-8859-* and the C1 controlrange] is an incredibly detailed look into the insane world of character encoding.
• You can still help us review HTML 5! Your input is important!

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

This item was originally posted at: http://blog.whatwg.org and is licensed under the MIT license

There has been very little spec-related activity this week, so I will briefly repeat Ian Hickson's request to Help us review HTML5 and then turn to a fascinating debate happening right now on the WHATWG mailing list.

The debate revolves around perceptions and expectations of privacy. Brady Eidson (Apple/WebKit) kicks off the discussion with Private browsing vs. Storage and Databases:

A commonly added feature in browsers these days is "private browsing mode" where the intention is that the user's browsing session leaves no footprint on their machine. Cookies, cache files, history, and other data that the browser would normally store to disk are not updated during these private browsing sessions.

This concept is at odds with allowing pages to store data on the user's machine as allowed by LocalStorage and Databases. Sur[e]ly persistent changes during a private browsing session shouldn't be written to the user's disk as that would violate the intention of a private browsing session. ...

1. Disable LocalStorage completely when private browsing is on. Remove it from the DOM completely.
2. Disable LocalStorage mostly when private browsing is on. It exists at window.localStorage, but is empty and has a 0-quota.
3. Slide a "fake" LocalStorage object in when private browsing is enabled. It starts empty, changes to it are successful, but it is never written to disk. When private browsing is disabled, all changes to the private browsing proxy are thrown out.
4. Cover the real LocalStorage object with a private browsing layer. It starts with all previously stored contents. Any changes to it are pretended to occur, but are never written to disk. When private browsing is disabled, all items revert to the state they were in when private browsing was enabled and writing changes to disk is re-enabled.
5. Treat LocalStorage as read-only when private browsing is on. It exists, and all previously stored contents can be retrieved. Any attempt to setItem(), removeItem(), or clear() fail.

Ian Fette (Google/Chrome) explains how Google Chrome handles LocalStorage in "incognito" mode:

[W]hilst the [incognito] session is active, pages can still use a database / local storage / ... / and at the end of the session, when that [temporary] profile is deleted, things will go away. I personally like that approach, as there may be legitimate reasons to want to use a database even for just a single session.

Darin Fisher (Google/Chrome) follows up to clarify Google Chrome's behavior:

Chrome's "incognito mode" means -- is defined as -- starting from a clean slate (as if you started browsing for the first time on a new computer), and when you exit incognito mode, the accumulated data is discarded. That's all there is to it. The behavior of LocalStorage and Database in this mode is deduced easily from that definition.

Jonas Sicking (Mozilla/Firefox) explains his opposition to option 5:

My concern with this is the same as the reason we in firefox clear all cookies when entering private browsing mode. The concern is as follows:

• A search engine stores a user-id token in a cookie. They then use this token to server side store the users 10 last searches.
• A user uses this search engine to search for various items. Doing this causes the user-id token to be stored in a cookie.
• The user then switches to private browsing mode.
• The user makes a search for a present for his wife.
• The user switches back into normal browsing mode.

At this point it is still possible to see the search for the wifes present in the websites store of recent searches.

Something very similar could happen for localStorage I would imagine, where the user-identifing information is stored in the localStorage rather than a cookie.

Josh "timeless" Soref (core Firefox developer) explores the privacy implications of different options:

[Option 1: Disabling LocalStorage won't work because] Many sites will just assume that they know a given useragent supports localstorage, so they'll be surprised and break. This will mean that a user can't use certain sites.

[Option 2: Enabling LocalStorage with 0 quota] will enable sites to know that the user is browsing in private, which is probably also a violation of the user's trust model. If I were to be browsing in private, I wouldn't want most sites to know that I'm doing this.

[Option 4 or 5: Starting with existing LocalStorage data] means the site will know who you are (on average), and is almost certainly never what the user wants.

Jonas Sicking (Mozilla/Firefox) tentatively states

For what it's worth, I believe we're currently planning on doing 2 in firefox.

Brady Eidson concludes:

I strongly share Jonas' concern that we'd tell web applications that we're storing there data when we already know we're going to dump it later. For 3 and 4 both, we're basically lying to the application and therefore the user.

... So far I'm standing by WebKit choosing #5 for now.

Drew Wilson summarizes his thoughts on the matter:

I think the #1 goal for incognito mode has to be "maximum compatibility" -- let sites continue to work, which kills options #1 & 2. A secondary goal for incognito mode would be "don't let sites know the user is in incognito mode" -- this kills approach #1 and #5, and possibly #2 (depending on whether there are significant non-incognito use cases that also have 0 local storage quota).

For my part, I agree with Drew, and I would add this: I use Google Chrome's "incognito mode" quite frequently when I'm developing websites. It's an easy way to test from a "blank slate" with no cookies and no cache, and it's much easier than juggling multiple profiles. If data in my LocalStorage "bleeds" into incognito mode, this use case would become unreliable and web development would be harder for me. (Bil Corry makes this point too.)

On a more philosophical level, it's nobody's business that I'm in private browsing mode. (Scott Hess makes this point too.) If authors can detect it, I consider that a serious bug. (Imagine the ha.ckers.org headline: "Safari Hole Allows Sites To Detect 'Private' Browsing, Punish Users.") Even worse, if LocalStorage could be used as a "super-cookie" for less-than-honorable sites to track me from normal usage to incognito usage, then it's not really "private browsing" in any sense of the word that matters.

In the early days of Greasemonkey, there were discussions of whether Greasemonkey should send or provide some detectable signal to page authors that Greasemonkey was running and the user had active scripts modifying the current page. To which I replied:

If Greasemonkey makes any overtures towards allowing web publishers to "opt out" or override my browsing experience in any way, I will immediately fork it and make it my life's mission to maintain the fork as long as possible.

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

This item was originally posted at: http://blog.whatwg.org and is licensed under the MIT license

The big news for the week of March 30^th is the addition of a synchronous database API to the Web Storage spec (which was split out from the HTML 5 spec a few weeks ago). This new API defines a DatabaseSync object whose methods return SQLTransactionSync objects. This directly mirrors the asynchronous database API, which had already defined a Database object whose methods return SQLTransaction objects. [r2958]

Another interesting change this week is r2921, which adds the placeholder attribute to the <textarea> element. I tracked the initial discussion of the placeholder attribute in episode 8 and noted its appearance in HTML 5 in episode 13. Previously you could only use the placeholder attribute on <input type=text>, <input type=email>, <input type=url>, and <input type=password>, but Thomas Broyer pointed out that Google Code (among others) uses placeholder text on <textarea> elements. Such sites could now theoretically migrate their current script-based solutions to HTML 5 markup.

Other interesting changes this week:

• r2928 recommends that browsers should reset the text-indent property when rendering a <textarea> element.
• r2930 notes a strange edge case where paragraphs (<p> elements) can end up overlapping each other if they are used as fallback content within an <object> element.
• r2933 adds event handler DOM attributes like onclick to the WebIDL definition of the document object.
• r2936 allows the spellcheck attribute to be present with no value, as a synonym for spellcheck="true". I first mentioned the spellcheck attribute in episode 23, and again in The Road to HTML 5: spellchecking.
• r2937 allows <textarea wrap=off>.
• r2941 further tweaks the algorithm for parsing legacy color attributes, which is trickier than you might think.
• r2943 allows the width and height attributes of an <img> element to be 0.

Around the web:

• Jacob Seidelin posts a <canvas> cheat sheet.
• Peter-Paul Koch knows way more about dates than you do.
• Eric Meyer uses HTML 5 to present the results of the "A List Apart Survey 2008."
• Alex Nicolaou explains how the new versions of Google Mail and Google Calendar use HTML 5 for offline functionality.
• Jon Tan talks about practical ways to tweak your markup now to migrate to HTML 5 later.
• addfullsize.com is an entire site devoted to adding an attribute to the <img> element.
• Anne van Kesteren thinks URLs are tough, and he's right.

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

This item was originally posted at: http://blog.whatwg.org and is licensed under the MIT license

The big news for the week of March 23^rd is that SVG can once again be included directly in HTML 5 documents served as text/html:

I've made the following changes to HTML5:

• Uncommented out the XXXSVG bits, reintroducing the ability to have SVG content in text/html.
• Defined <script> processing for SVG <script> in text/html by deferring to the SVG Tiny 1.2 spec and blocking synchronous document.write(). The alternative to this is to integrate the SVG script processing model with the (pretty complicated) HTML script processing model, which would require changes to SVG and might result in a dependency from SVG to HTML5. Anne would like to do this, but I'm not convinced it's wise, and it certainly would be more complex than what we have now. If we ever want to add async="" or defer="" to SVG scripts, then this would probably be a necessary part of that process, though.
• Added a paragraph suggesting: "To enable authors to use SVG tools that only accept SVG in its XML form, interactive HTML user agents are encouraged to provide a way to export any SVG fragment as a namespace-well-formed XML fragment."
• Added a paragraph defining the allowed content model for SVG <title> elements in text/html documents.

r2904 (and, briefly, r2910) give all the details of this solution. There are still a number of differences between the text in HTML 5 and the proposal brought by the SVG working group. Some of these are addressed further down in the announcement:

• SVG-in-XML is case-preserving; SVG-in-HTML is not.
• SVG-in-XML requires quoted attribute values; SVG-in-HTML does not.
• When SVG-in-XML uses CDATA blocks, they show up as CDATA nodes in the DOM; when SVG-in-HTML uses CDATA blocks, they show up in the DOM as conventional text nodes. [Clarified based on Henri's feedback]
• The <svg> element can not be the root element of a text/html document.

Doug Schepers, who has been the SVG working group's HTML 5 liason, does not like this solution:

To be honest, I think it's not a good use of the SVG WG's time to provide feedback when Ian already has his mind made up, even if I don't believe that he is citing real evidence to back up his decision. What I see is this: one set of implementers and authors (the SVG WG) and the majority of the author and user community (in public comments) asking for some sort of preservation of SVG as an XML format, even if it's looser and error-corrected in practice, and a few implementers (Jonas and Lachy, most notably) disagreeing, and Ian giving preference to the minority opinion. Maybe there is sound technical rationale for doing so, but I haven't been satisfied on that score.

Turning to technical matters, one of the features of web forms in HTML 5 is allowing the attributes for form submission on either the <form> element (as in HTML 4) or on the submit button (new in HTML 5). Originally, the attributes for submit buttons were named action, enctype, method, novalidate, and target, which exactly mirrored the attribute names that could be declared on the <form> element.

However, in January 2008, Hallvord R. M. Steen (Opera developer) noted that "INPUT action [attribute] breaks web applications frequently. Both GMail and Yahoo mail (the new Oddpost-based version) use input/button.action and were seriously broken by WF2's action attribute."

Following up in November 2008, Ian Hickson replied, "I notice that Opera still supports 'action' and doesn't seem to have problems in GMail; is this still a problem?" to which Hallvord replied, "GMail fixed it on their side a while ago. It is still a problem with Yahoo mail, breaking most buttons in their UI for a browser that supports 'action'. We work around this with a browser.js hack. ('Still a problem' means 'I tested this again a couple of weeks ago and things were still broken without this patch'.)"

Ian replied, "This is certainly problematic. It's unclear what we should do. It's hard to use another attribute name, since the whole point is reusing existing ones... can we trigger this based on quirks mode, maybe? Though I hate to add new quirks." Hallvord did not like that idea: "In my personal opinion, I don't see why re-using attribute names is considered so important if we can find an alternative that feels memorable and usable. How does this look? <input type="submit" formaction="http://www.example.com/">"

Finally, in March 2009, Ian replied:

That seems reasonable. I've changed "action", "method", "target", "enctype" and "novalidate" attributes on <input> and <button> to start with "form" instead: "formaction", "formmethod", "formtarget", "formenctype" and "formnovalidate".

And thus we have r2890: Rename attributes for form submission to avoid clashes with existing usage.

Other interesting changes this week:

• r2889 adds support for select.add(e) and select.options.add(e) with no second argument.
• r2888 defines how to determine the character encoding of Web Worker scripts. Briefly, it says to look for a Byte Order Mark, then look at the Content-Type HTTP header, then fall back to UTF-8.
• r2898, r2899, r2901, r2914, and r2916 define a locking mechanism to allow thread-safe read/write access to document.cookie and .localStorage. The lock is acquired during page fetching (which sets the cookie based on HTTP headers) and released once the cookie is set. It is also released automatically whenever something modal happens (such as window.alert()). (I first mentioned the discussion of this issue in episode 27. The problem is that Web Workers allows threaded client-side script execution, which means access to shared storage like document.cookie needs to be made explicitly thread-safe with some sort of locking mechanism.)

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

This item was originally posted at: http://blog.whatwg.org and is licensed under the MIT license

• Greg Millam writes, "I'm one of the main engineers responsible for captioning support on YouTube, and I've joined the Chrome team at Google to attempt to help drive video captions and subtitling forward." Henri Sivonen replies, "I agree it makes sense to start with something simple. The markupless flavor of SRT would be such a format. However, supporting the formatting tags in later flavors of SRT is a can of worms." [full thread: Captions, Subtitles, and the Video Element]
• Robert O'Rourke writes, "Are there any plans to bring list headers from HTML3 into HTML5?" Ian Hickson replies, "You can do this in HTML5, using <figure> and <legend>." The thread continues in a number of directions. Marcus Ernst writes, "Anyway I would consider it even more appropriate to allow the list inside a paragraph," to which Ian replies, "We had this in the spec originally, but we dropped it due to a variety of issues (it made life harder for editors, it didn't work in text/html even when it looked like it did, people got confused...)." [full thread: List Headers]
• Drew Wilson writes, "There's currently no way to set or get cookies from workers, which makes various types of cookie-based operations problematic." Jonas Sicking replies, "Allowing cookie to be set would unfortunately create a synchronous communication channel between the worker and the main window." The discussion continues, focusing on issues of multi-threaded updates to document.cookie. Drew Wilson again: "Following up on this. I created two pages, one that tests cookies in a loop, and one that sets cookies in a loop, and ran them in separate windows in Firefox 3, IE7, and Chrome. Chrome and IE7 currently allow concurrent modification of document.cookies (i.e. the test loop throws up an alert). Firefox does not." [full thread: Accessing cookies from workers]
• There have been a number of overlapping discussions on whether and how to allow authors to embed RDFa in HTML 5 documents. See 1, 2, 3, and followups. Besides the technical arguments about how it would work, much of the discussion centers around the concept of distributed extensibility, which I've touched on before. For example, here is Chris Wilson (of the Microsoft IE development team): "We have had (in the past as well, imo, in the future) a requirement for decentralized extensibility - that is, that document/content authors can extend the set of elements with their own semantic or behavioral elements. I continue to think there is a requirement for that. (One might well ask why we didn't implement full XML in that case; I'll politely not answer from a historical context, but will point out that the draconian error handling and poor fallback story make delivering content in XML in the browser a poor solution in the ecosystem today.)"
• Steven Faulkner writes, "I have ... taken a stab at a RFC 2119 compatible definition for table summaries: http://esw.w3.org/topic/HTML/SummaryForTABLE/SummarySpecification." [full thread: Draft text for summary attribute definition, continued in March archives]

There has also been a vigorous debate about the license of the specification itself.

• Sam Ruby writes, "In my discussions with Ian and at Mozilla, I gathered that it was a shared understanding that by October that the license for the W3C license would be somehow open source friendly, and specifically that a Creative Commons Attribution license was something that was of common and general interest." The "open source friendly" clause is a reference to the fact that the spec does actually contain some code (in the form of WebIDL declarations), and vendors of open source browsers would like to include this code (or derive code from it) into their products.
• After much discussion, Philippe Le Hegaret (of the W3C) writes, "In response to requests from developers to make it easier to include portions of W3C specifications in software documentation, bug reports, code, and test cases, W3C have drafted a new Excerpt & Citation License. ... Uses like forking of a specification would remain prohibited to protect the due process and the consensus found in a chartered Working Group."
• Ian Hickson immediately replies, "Increasing license proliferation is a really bad idea here. I would be opposed to introducing yet another license. ... [The forking] use case is the main one that I'm concerned about, FWIW."
• Jonas Sicking explains his reasoning about allowing forking: "I think it would gain W3C a tremendous amount of trust if it were to allow [forking]. To many people, me included, having the gurentee that W3C can't go off 'into the weeds' means that I have don't have to worry about my time being wasted when I contribute. I think many people feel the same when they contribute to the forkable software I represent."
• Philippe notes that the W3C "isn't used to the concept of allowing a fork" of their specifications, which is one of the requirements of any "open source friendly" license.
• I believe Maciej Stachowiak (WebKit developer at Apple) best summarized the group's objections: "1) Preventing specification forks is not achievable through license terms; a sufficiently motivated party can create a new spec from scratch. 2) Preventing specification forks is probably not necessary; the one time it happened, the outcome was good and the effort merged back into a realigned W3C. 3) Due to 1 and 2, we should give more consideration to LGPL/GPL compatibility than prevention of forks via licensing terms."
• Ian Hickson agrees: "I do agree that the original use cases are (intentionally and explicitly) not all met by the proposal that was put forward, and I do think the original use cases were an accurate portrayal of the use cases that this working group has consensus on. Compatibility with open source (including GPL and LGPL projects), clear license terms (ideally reusing an existing license), and the ability to fork are all issues that working group members discussed and considered important previously."

[Further reading: Discussions with plh, Draft W3C Excerpt License]

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

This item was originally posted at: http://blog.whatwg.org and is licensed under the MIT license

The big news for the week of March 16^th is this announcement from Ian Hickson:

I've now split out the Server-sent Events and Storage APIs out of HTML5, and I've removed the text for Web Sockets, which was split out earlier. By popular demand I've also done some tweaks to the styling of these specs.

HTML5

http://dev.w3.org/html5/spec/

Server-Sent Events

http://dev.w3.org/html5/eventsource/

Web Storage

http://dev.w3.org/html5/webstorage/

Web Workers

http://dev.w3.org/html5/workers/

Web Sockets

http://dev.w3.org/html5/websockets/
http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol

It is my understanding that the desire is to publish the Server-Sent Events, Web Storage, Web Workers, and Web Sockets specs through the Web Apps working group, so that is what I put into the "status of this document" sections.

I would like to be able to put more permissive licenses (ideally MIT) on these drafts, rather than the W3C license.

The following sections still haven't been split out:

URLs

I'll remove this section as soon as DanC's draft is published.

Content-Type sniffing

I'll remove this section once Adam's draft is on a standards track.

Timeout API

This section is lacking an active editor.

Origin

I'm unsure what will happen with this section.

In IRC, Ian explained that all of these documents are generated from one master file:

# [21:02] <hixie> the source document is run through a bunch of scripts to generate the output documents
# [21:03] <hixie> from that one file i now generate one whatwg spec, four w3c specs, and an rfc

In other news, r2876 (WARNING: VERY LARGE) adds user stylesheets to the HTML 5 specification itself. If you view it in a browser that support switching stylesheets (such as Firefox, under the View → Page Style submenu), you can choose between "Complete specification" (default), "Author documentation only," or "Highlight implementation requirements." The "Author documentation only" stylesheet hides all of the client parsing algorithms and focuses on the elements, attributes, and scripting features that web authors need to know about.

For example, the "author documentation" of the <img> element highlights the required attributes, how to create a new Image() dynamically, and the detailed requirements for providing alternate text, while completely hiding any mention of how image fetching fits into the client's task queue, the gory details of how clients resolve image URLs, or the security risks of allowing pages on the public internet to attempt to load images on the local network. On the flip side, "highlight implementation requirements" highlights these exact issues.

Critics who complained that the HTML 5 specification should be "just a markup language" will be able to have their cake and eat it too. Those who complained that HTML 5 was "too bloated" will have a little less to complain about now that several parts of it have been published as separate documents. On the other hand, critics who complained about these things as a cover for other agendas will have to continue complaining a little while longer.

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

This item was originally posted at: http://blog.whatwg.org and is licensed under the MIT license