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 »
Thursday, April 23rd, 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 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."
Posted in Weekly Review | 8 Comments »
Wednesday, April 8th, 2009
Welcome back to "This Week in HTML 5," where I'll try to summarize the major activity in the ongoing standards process in the WHATWG and W3C HTML Working Group.
The big news for the week of March 30th 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:
Tune in next week for another exciting episode of "This Week in HTML 5."
Posted in Weekly Review | 2 Comments »
Thursday, April 2nd, 2009
Welcome back to "This Week in HTML 5," where I'll try to summarize the major activity in the ongoing standards process in the WHATWG and W3C HTML Working Group.
The big news for the week of March 23rd 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."
Posted in Weekly Review | 3 Comments »
Tuesday, November 25th, 2008
Welcome back to "This Week in HTML 5," where I'll try to summarize the major activity in the ongoing standards process in the WHATWG and W3C HTML Working Group.
The big news this week is a radical proposal for integrating HTTP authentication with HTML forms. r2432 defines a new token for the WWW-Authenticate header: "HTML".
A common use for forms is user authentication. To indicate that
an HTTP URL requires authentication through such a form
before use, the HTTP 401 response code with a WWW-Authenticate challenge "HTML" may be used.
For this authentication scheme, the framework defined in RFC2617
is used as follows. [RFC2617]
challenge = "HTML" [ form ]
form = "form" "=" form-name
form-name = quoted-string
The form parameter, if
present, indicates that the first form element in the
entity body whose name is the
specified string, in tree order, if any, is the login
form. If the parameter is omitted, then the first form
element in the entity body, in tree order, if any, is
the login form.
There is no credentials production for this
scheme because the login information is to be sent as a normal form
submission and not using the Authorization
HTTP header.
This idea has been kicked around for more than a decade. Microsoft wrote User Agent Authentication Forms in 1999. Mark Nottingham asked the WHATWG to investigate the idea in 2004. Better late than never, Ian Hickson summarizes the feedback to date. No doubt this new proposal will generate further discussion. No browsers currently support this proposal.
Other interesting tidbits this week:
- r2429 adds the
<input type=search> form field. [<input type=search> discussion]
- r2440 allows the
multiple attribute to appear on <input type=email> and <input type=file>. [<input type=email multiple> discussion]
- r2423 specifies how
<object> elements are submitted in forms. Unbeknownst to me, this feature was present in HTML 4 and is supported across multiple browsers. If a plugin exposes a value getter, the name of the <object> element is submitted with the value exposed by the plugin. [<object> form submission example, Mozilla bug 188938]
- r2434 seriously revamps the concept of "vaguer moments in time." r2433 notes, correctly, that there is no year zero in the Gregorian calendar. r2437 further refines the calculation of dates before 1582. [date and time discussion]
- r2426 clarifies the fallback behavior of the
<object> element.
- r2427 documents existing browser behavior in sending all attributes and attribute values to a plugin invoked from an
<object> element. Previously, HTML 5 has specified that only specific parameters were sent, but browsers consistently send all attributes, so there it is.
- r2424 explains the intended audience of the HTML 5 specification itself.
Tune in next week for another exciting episode of "This Week in HTML 5."
Posted in Weekly Review | 7 Comments »