Please leave your sense of logic at the door, thanks!

This Week in HTML5 – Episode 35

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:

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 »

This Week in HTML 5 – Episode 31

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:

textSimple text.
editableEditable text.
checkableText with a check box.
listA list of values that the user can switch between.
progressA progress bar.
meterA gauge.
customA 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.

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

Posted in Weekly Review | 8 Comments »

This Week in HTML 5 – Episode 12

Tuesday, November 11th, 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 primary editor was traveling this week, so there are very few spec changes to discuss. Instead, I'd like to try something a little different.

It has been suggested (1, 2, 3, &c.) that HTML 5 is trying to bite off more than it can metaphorically chew. It is true that it is a large specification, and it might benefit from being split into several pieces. But it is not true that it includes everything but the kitchen sink.

For example, HTML 5 will not

Daniel Schattenkirchner asked whether Almost-Standards mode is still needed. Almost-Standards mode is a form of DOCTYPE sniffing invented by Mozilla in 2002 to address line heights in table cells containing images. Bug 153032 implemented the new mode, which Mozilla called "Almost Standards mode" and HTML 5 calls "limited quirks mode." Henri Sivonen made the point that it would probably be too expensive to get rid of the mode. Like it or not, we're probably stuck with it.

And finally, a gem that I missed when it was first discussed: back in July, "Lars" provided the best documentation of the <keygen> element, ever.

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

Posted in Weekly Review | 3 Comments »