Tuesday, October 20th, 2009
Welcome back to "This Week in HTML 5," where I'll try to summarize the major activity in the ongoing standards process in the WHATWG and W3C HTML Working Group.
This week, there were some more refinements to microdata. r4139 changes the names of the DOM properties that reflect microdata markup. r4140 renames the content property to itemValue Since no browser has actually implemented this API yet, these changes shouldn't make any difference. Standards are like sex; one mistake, and you're stuck supporting it forever! r4141 and r4147 fix up some microdata examples, in particular this example from Gavin Carothers about marking up O'Reilly's book catalog. Hooray for real-world examples!
There were also some noteworthy changes to the <video> and <audio> API. r4131 says that setting the src attribute on one of those elements should call its load() method. r4132 removes the load event for multimedia elements, and r4133 removes the "in progress" events (loadstart, loadend, and progress) that used to be fired while the video/audio file was downloading.
Other noteworthy changes this week:
- r4097 defines fallback content for the obsolete
<applet> element.
- r4098 "dramatically simplifies
<script defer> and <script async> handling." [Background: bug 7792]
- r4106 makes the step argument to the
<input> element's stepUp() and stepDown() methods optional.
- r4111 removes
<link rel=feed>. As I documented earlier this year, rel=feed was a reasonable idea that never took off. Only one browser ever implemented it, and in a survey of 3 billion pages I could only find a single page that used it.
- r4126 lists suggested default encodings for different locales. [Background: RE: HTML5 Issue 11 (encoding detection): I18N WG response...]
- r4138 drops support for non-UTF-8 encodings in Web Workers. [Background: [whatwg] Please always use utf-8 for Web Workers]
- r4099 marks the creation of Web Applications 1.0, a super-spec that contains HTML5, pre-defined microdata vocabularies, Web Workers, Web Storage, Web Database, Server-sent Events, and Web Sockets. This marks the first time that some of those specs have been published by the WHATWG, rather than the W3C, and therefore the first time that said specs have been published under a Free-Software-compatible license. (The W3C is still deciding whether to use such a license.)
Around the web:
Tune in next week for another exciting edition of "This Week in HTML5."
Posted in Weekly Review | 5 Comments »
Friday, October 9th, 2009
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:
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:
Tune in next week for another exciting edition of "This Week in HTML5."
Posted in Weekly Review | 2 Comments »
Sunday, September 27th, 2009
Since I started publishing these weekly summaries over a year ago, I've watched the HTML5 specification grow up. In episode 1, the big news of the week was the birth of an entirely new specification (Web Workers). Slowly, steadily, and sometimes painstakingly, the HTML5 specification has matured to the point where the hottest topic last week was the removal of a little-used element (<dialog>) and the struggle to find a suitable replacement for marking up conversations.
This week's changes are mundane, and I expect (and hope!) that future summaries will be even more mundane. That's a good thing; it tells me that, as implementors continue implementing and authors continue authoring, there are no show-stoppers and fewer and fewer "gotchas" to trip them up. Thus, the overarching theme this week -- and I use the term "theme" very loosely -- is "the never-ending struggle to get the details right."
Parsing
HTML5 is full of algorithms. Most of them are small parts of one mega-algorithm, called Parsing HTML Documents. Contrary to popular belief, the HTML parsing algorithm is deterministic: for any sequence of bytes, there is one (and only one) "correct" way to interpret it as HTML. Notice I said "any sequence of bytes," not just "any sequence of bytes that conforms to a specific DTD or schema." This is intentional; HTML5 not only defines what constitutes "valid" HTML markup (for the benefit of conformance checkers), it also defines how to parse "invalid" markup (for the benefit of browsers and other HTML consumers that take existing web content as input). And sweet honey on a stick, there sure is a lot of invalid markup out there.
- r3896 tells parsers to ignore almost any end tags before the
<html> tags. There are a few special end tags which cause the parser to start constructing a new document: </html>, </head>, </body>, and oddly enough, </br>. [Related: Bug 7672]
- r3909 clarifies how user agents should parse the
type attribute of a <script> tag. The type attribute is optional; authors can simply omit it if they're embedding JavaScript.
- r3923 tweaks the algorithm for parsing the
DOCTYPE declaration. This affects DOCTYPE sniffing.
- r3967 clarifies the algorithm for ignoring the first newline or carriage return character at the beginning of a
<pre> block. [Background: [whatwg] Initial carriage return in <pre> and <textarea>]
- r3968 explains why the
<embed> element can have an infinite number of attributes. (Answer: because they are passed directly to the third-party plugin that handles the embedded content, and there are no restrictions on what kind of plugins you can have or what attributes they can take as input.)
- r3991 adds to the already-long list of legacy, non-conforming attributes that user agents may encounter in existing web content.
- r3871 and r3982 tweak the handling of Unicode surrogates. [Background: [whatwg] Surrogate pairs and character references]
Accessibility
As with so many things in the accessibility world, all of this week's changes revolve around the thorny problem of focus. I previously explained why focus is so important in episode 24.
- r3887 specifies that each
<area> in a client-side image map should be focusable.
- r3919 encourages browser vendors to expose tooltips to keyboard-only users. For example, in Firefox 3.5, if you hover your cursor over a hyperlink that defines a
title attribute, you will see the title attribute as a tooltip. But if you tab to the same link with the keyboard, no tooltip appears. Now imagine that you're physically unable to use a mouse, and you begin to see the problem. [Background: Bug 7362 and Issue 80]
- r3928 defines an intriguing proposal about canvas accessibility, which probably deserves its own article. Here's the short version: you can already define "fallback content" within a
<canvas> element that is shown to browsers that don't support the canvas API. This change dictates that the "fallback content" should remain keyboard-focusable even in browsers that do support the canvas API. To quote the spec: "This allows authors to make an interactive canvas keyboard-focusable: authors should have a one-to-one mapping of interactive regions to focusable elements in the fallback content." This is a draft proposal; as far as I know, no browser actually supports it yet, and it may get reverted in the future. [Background: Bug 7404]
- r3969 clarifies that browsers must do nothing when the user activates a label whose corresponding input control is hidden (in any manner, including a
display: none CSS rule). [Background: Bug 7583]
Security
All of this week's security-related changes revolve around document.domain. As you might expect from its name, this property returns the domain name of the current document. Unfortunately (for security), the property is not read-only; you can also set document.domain to pretty much anything. This can cause all sorts of horrible side effects, since so many things (cookies, local storage, same-origin restrictions on XMLHttpRequest) rely on the domain of the document. This set of changes attempts to reduce the nasty side effects (and the possible attack surface) in case you absolutely must set document.domain to something other than its default calcuated value.
Semantics
- r3905, r3948, and r3966 clarify that the
profile attribute (used by various microformats) takes a space-separated list of addresses, not just a single address. This has been the subject of heated debate for over 12 years, because HTML 4 claims that "the value of the profile attribute is a URI; user agents may use this URI in two ways..." while simultaneously claiming that "this attribute specifies the location of one or more meta data profiles, separated by white space." [Background: let's keep metadata profiles (head/@profile) in HTML for use in GRDDL etc., [whatwg] HTML4's profile="" attribute's absence in HTML5, Bug 7413, Bug 7484, Bug 7512, and Issue 55.]
- r3869 tweaks the definitions of
<section>, <article>, and <details> based on an informal study by Jeremy Keith. r3979 further tweaks the definition of <article>, and r3978 mentions that the <article> element is semantically similar to the <entry> element in RFC 4287 (Atom Syndication Format). [Background: [whatwg] article/section/details naming/definition problems. Related: Bug 7551]
- r3954 further clarifies the definition of
<footer>. [Background: Bug 7502]
- r3907 clarifies the workings of the registries for the enumerated values of
<link rel>, <meta name>, and <meta http-equiv> attributes.
- r3904 tweaks the semantics of
<link rel="up">.
- r3962 modifies the outline algorithm (used to generate a kind of "table of contents" of an HTML document based on sections and headers) to handle an obscure edge case. [Background: IRC discussion of edge case, Bug 7527, and in particular this comment on Bug 7527]
- r3987 gives an example to clarify that the
<nav> element does not always need to be a child of a <header> element.
Video
As regular readers of this column are aware, one of the big new user-visible features of HTML5 is native video support without plugins. As video is incredibly complicated, so to is the video support in HTML5. (Although not related to this week's changes, you may be interested to read my series, A gentle introduction to video encoding.)
- r3867 modifies the algorithm for sizing anamorphic video within a
<video> element, and r3913 defines how to display a frame of anamorphic video in a canvas pattern. [Background: Re: video size when aspect ratio is not 1, What The Heck Is Anamorphic?]
- r3924 defines what happens when you dynamically insert a
<source> element as a child of a <video> element that also has a src attribute, and r3925 defines what happens when you dynamically remove a <video src> attribute. [Background: Bug 7631, Bug 7632]
- r3927 gives advice on how browsers could render an
<audio> element with a controls attribute.
- r3992 makes further refinements to the
play() and pause() algorithms.
Forms continue to be difficult.
- r3874 allows browsers to reset the list of selected files of an
<input type="file"> element by setting its value attribute to the empty string. [Background: [whatwg] Setting .value on <input type=file>]
- r3922 clarifies that setting the
disabled attribute of a <fieldset> element should not disable the children of the fieldset's <legend> element. [Background: Bug 7591]
- r3934 defines that the
maxLength property should return -1 on a <textarea> or <input> element that does not include a maxlength attribute. [Background: Bug 7427]
- r3957 clarifies that implicit form submission should validate the form first. [Background: Bug 7511]
Interesting Discussion Threads This Week
Around the Web
Tune in next week for another exciting edition of "This Week in HTML5."
Posted in Weekly Review | 1 Comment »
Wednesday, September 16th, 2009
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:
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:
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."
Posted in Weekly Review | 10 Comments »
Wednesday, September 2nd, 2009
In last week's episode, I mentioned that the HTML 5 specification now includes a media registration for text/html. Ian Hickson explains why HTML 5 re-registers text/html: "The main thing that needs updating is the removal of the permission for sending syntactic profiles of XML as text/html. In addition, the encoding considerations, fragment identifier definition, and the text about recognising HTML documents are somewhat out of date and can be significantly improved by referencing HTML5 now."
This addition has not been without controversy. For example, Julian Reschke believes that "RFC 2854 applies to all HTML vocabularies (and references them), while HTML5 just describes the 'current' language." [ensuing discussion] I personally disagree that HTML 5 needs to define all elements and attributes of previous HTML versions in order to "earn" the right the re-register text/html, but it is true that HTML 5 does not do so. Or didn't, before r3683 added a definition of the <meta scheme> attribute and a definition for the <head profile> attribute. So there's that.
In other news:
- r3685:
drawImage() and createPattern() (methods of a <canvas> element's drawing context) no longer throw an exception if the image isn't ready. Instead, they return null. [Simon Pieters: drawImage() shouldn't throw INVALID_STATE_ERR]
- r3726: Add support for
aria-level for headings. An HTML document is an outline, as defined by its sections and headers. ARIA allows the browser to expose this outline to assistive technologies. This revision ensures that the current heading level in the outline is also exposed. [Steven Faulkner: Re: question about ARIA in HTML 5 spec text - implied use on elements not listed, although the final solution is more complicated than that because of how headers interact with nested sections]
- r3679 removes the normative reference to Unicode Technical Standard 22, which defines the method for comparing names of character encodings. If you thought character encoding itself was complicated, just wait until you try to implement character encoding aliases!
- r3717 adds another "willful violation" to HTML 5, this time of RFC 5322, which "defines a syntax for e-mail addresses that is simultaneously too strict (before the '@' character), too vague (after the '@' character), and too lax (allowing comments, white space characters, and quoted strings in manners unfamiliar to most users) to be of practical use here." [TAMURA Kent: type=email validation is too loose for practical applications]
- r3725 changes the Web Sockets API to use ports 80 (for normal traffic) and 443 (for encrypted traffic), based on a recommendation from the IANA. It had previously specified ports 81 and 815.
Interesting discussion of the week: Web Storage: apparent contradiction in spec. At issue is how much freedom browsers should have to manage their client-side state, including cookies, local databases, and local storage. On one side is Linus Upson, project manager of Google Chrome: "It is important that all local state be treated as a cache. User agents need to be free to garbage collect any local state. If they can't then attackers (or the merely lazy) will be able to fill up the user's disk." On the other side is Brady Eidson of Apple: "One key advantage of LocalStorage and Databases over cookies is that they *do* have a predictable, persistent lifetime, and the browser is *not* allowed to prune them at will. ... [O]nce the data is stored, it should be considered user data - as 'sacred' as a user's file on the file system." Linus responds: "If the spec requires UAs to maintain local storage as 'precious' it will be the first such feature in HTML 5. Everything else in the spec is treated as volatile." It goes on like that for a while. Schuyler Duveen presents some use cases. Boris Zbarsky (Mozilla) thinks it's a matter of trust. The entire thread highlights the multiple trains of thought for what local storage is for, what it means, and how it should be treated.
Posted in Weekly Review | 2 Comments »