Dear reader, if you had any hope HTML 5 would make it to last call by October 2009 then this email to the HTML WG from the Microsoft IE team will conveniently take you back to reality.
Summary
I tried to summarize Microsoft’s response in a few witty lines, but I couldn’t do it. Instead I ended up with this mess of ideas that I’ve left below.
New Elements
Microsoft’s Internet Explorer team isn’t keen on implementing some of HTML 5’s new elements as currently spec’d:
<section><nav><article><aside><hgroup><header><footer><dialog><mark><time><progress><meter><datagrid>
Their reasoning for push back generally suggest that the elements are unnecessary, handled fine by a scripting library, or too underspecified to be interoperably implemented, though it is worth reading the entire email to understand their issues with each piece.
I will happily concede that adding <aside>, <header> and <footer> seem somewhat unnecessary if they don’t provide any additional UA or DOM features. On the flip side, as someone who regularly uses screen-scraping I can see a lot of potential in having these elements but suspect they won’t be used properly anyway. To be fair, I don’t think implementations are that far along on the new sectioning elements though they have gathered mostly positive feedback from the HTML authoring community.
keygen
They’d also rather not reintroduce <keygen> because they’ve deprecated support for it as of Windows 7 and they don’t feel that adoption is wide-spread enough to warrant inclusion.
input@type=date
For the new date-based HTML form input types (<input type="date|time|datetime|local-datetime">) they’d like to see better time-zone related language than “User agents must not allow the user to set the value to a string that is not a valid global date and time string expressed in UTC, though user agents may allow the user to set and view the time in another time zone and silently translate the time to and from the UTC time zone in the value.” given the complexity of time-zones.
bb
Their comments on <bb>, a “user-agent button”, are somewhat humorous:
Having a consistent installation experience for independent applications is the key to their success. Supporting the instantiation of individual apps through a page control provides too much programmable flexibility that developers could use to hijack the end-user experience thus creating an inconsistent process.
I would never use the phrase “Consistent installation experience” to define my time spent using Microsoft products or products developed by 3rd party developers for the Microsoft ecosystem. That said, every team in Microsoft is unique and I do believe that the current Internet Explorer team places a high value on user experience.
Their comments go on to suggest a number of improvements to the <bb> element (particularly around the scripting model and where it should live in the DOM) that I think are quite sensible. This is the probably the first substantive feedback I’ve seen on <bb>, so kudos to Microsoft. (Update: Mozilla chimes in on <bb>.)
menu
They ding <menu> because their experience suggests that:
web developers want precise user agent independent control over the layout of their UI
Well sure, but it does feel like <menu> (and <progress> & <meter> also mentioned again in this section) have distinct benefits for assisted technologies (AT). If we’re going to leave table@summary conforming because of the promise it holds for AT then surely new elements that could be very beneficial for the same set of users seems reasonable. I do sense that their concerns here are not outright dislike for this element but much more about getting feedback from fellow user-agent implementors on whether this element should be specified in more detail.
contenteditable & UndoManager
These are two APIs: contenteditable is for implementing WYSIWYG HTML editing and UndoManager is a proposed method for dealing with rolling back changes to the DOM. That they knock contenteditable for being underspecified is somewhat funny because it is a Microsoft feature that several browsers and HTML 5 have had to reversed engineer due to lack of detailed public documentation. Maybe Microsoft could offer take over editorship for this portion of the spec.
I’m honestly not even sure why they commented on UndoManager given that the draft contains the following language about it:
This API sucks. Seriously. It’s a terrible API. Really bad. I hate it.
Perhaps it is worthwhile to starting calling out these sections in hopes of pulling them from the draft now. If that was the intent, then I can get behind that.
Conclusions
In general I’m excited that Microsoft is commenting on HTML 5 but I’m also quite concerned at the nature of their comments given how far along HTML 5 is. Regardless of what Adobe would have you think, the HTML 5 ship has in fact left the station, mostly thanks to the mobile user agents in use on Android devices, Apple iPhones, and Palm Pres.