The WHATWG Blog

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

This Week in HTML5 – Episode 35

by Mark Pilgrim, Google in Weekly Review

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

↔

10 Responses to “This Week in HTML5 – Episode 35”

  2. Would the “around the web” list be better by using <dl>?

    The credited link to each piece of work would be the <dt>.
    The subsequent description and commentary would be the <dd>.
    Entries without descriptions would either use an empty <dd> or could have a description added.

    Seems a good fit, to me.

    I did make some styles for <dl> in this theme. Not sure if they look any good, though.

    Oh, here’s another odd thing: the name of the authors use <cite> while the title of their works do not. The use of a colon after the name makes it look a bit like the rest of the item is something they said or wrote, when most of it is usually your comments.

    I’d probably avoid <cite> and write:

    <a href="http://www.alertdebugging.com/2009/08/16/on-html-5-drag-and-drop/">On HTML5 Drag and Drop</a> by Francisco Ryan Tolmasky:

    Which, after using <dl> and adding a description, looks like this:

    On HTML5 Drag and Drop by Francisco Ryan Tolmasky:
    Uses a theme a bit like The WHATWG Blog.

    (Looks like I forgot to give <dl> a margin-bottom.)

    I also notice the blog isn’t using curly quotes. You can really see the difference when using Verdana, so that might be worthwhile. I expect their are plugins which automate the common cases.

    Preview for comments would be nice. Especially when writing codey ones like this!

    (Not trying to pick holes. Just thinking aloud about possible improvements.)

    First time I submitted my comment, I got this error message:

    Hmmm, your comment seems a bit spammy. We’re not real big on spam around here.

    Please go back and try again.

  3. The comment system seems to strip all the list markup. Replaced it with <p> and <br>. I used a <ul> with 3 items near the start and a <dl> in the example item.

    The missing margin-bottom is not apparent in the comment. That’s because the <dl> was stripped after I submitted it. It was apparent in my local test page.

    Also, strangely, the <samp> I used around each line of the error message was stripped.

    Oh, it also converted the <pre><code> into <p><code> for the block of HTML.