Dave Hyatt and the Safari team have been busy lately adding support for a number of extensions to html to be used by the upcoming Safari RSS reader and Dashboard. On the list is IE’s contenteditable, along with a slider widget, search fields, a composite attribute on the <img/> element, and a new <canvas/> element.
This has generated a fair amount of concern in the web developer community. Tim Bray and Eric Meyer both worry that this heralds a return to the bad old days of the browser wars with everyone just ignoring the standards and making things up for themselves. Specifically, they point out that instead of trying to put new elements into HTML, they could have used XHTML, which, being XML, is designed to be extensible with namespaces or at the very least used a different DOCTYPE. Dave has responded with an explanation of why they did things the way they did.
Dave argues that the XML and namespaces approach has implementation issues. I’m not enough of an expert on browser internals to say whether this is a cop-out or not, so I guess we’ll have to trust him on that. He also says that:
“However, this would have dramatically increased the complexity of crafting Dashboard widgets. People know how to write HTML, but most of those same people have never written an XML file, and namespaces are a point of confusion.
Would the increase in complexity in the markup really be that much of an obstacle? Dashboard widgets seem to me like the kind of thing that would be written by a programmer, or at least have an expectation of being a little more strict than a regular web-page. Besides, web developers have historically shown an incredible aptitude for blindly copy-pasting markup. There’s an awful lot of RDF out on the web. Somebody had to write it.
He also doesn’t address the suggestion of at the very least creating their own DTD with their extensions and using a DOCTYPE that points at that DTD. This would go a long way towards alleviating the whole “polluting HTML” concern. I haven’t really seen any actual real-world examples of this markup in action, so for all I know they’ve already done this or are planning to.
While I can understand and respect the following:
“In other words, in an ideal world where we had two years to craft Dashboard, maybe we could have used XHTML and SVG, but we aren’t living in that ideal world. We can basically manage only one “huge” layout engine feature in a development cycle, and given our developer feedback the choice of HTML editing as the feature to focus on this cycle was clear. We would still love to implement SVG and XSLT and other great technologies in the future, but we simply can’t do everything at once.”
It does sound an awful lot like the “Our customers don’t care about standards support. They want fancy new features” excuse that we’ve been hearing from browser vendors for years and that the WaSP has been actively trying to debunk.
The fact that they’re actively working with other browser makers, with the WHAT WG, and seem to have intentions of eventually getting the extensions approved by the W3C is somewhat reassuring.
Overall, though, it’s not that big a deal. Safari does an excellent (not perfect) job of supporting the various HTML, XHTML, and CSS specs as they’re written and ultimately, that’s what’s most important. If developers don’t want to use the extensions, they don’t have to. The vision that the WaSP has been most adamant about is that developers should be able to build sites that conform to the published specs and have them Just WorkTM in every browser. If browsers want to support additional proprietary extensions on top of that, they’re free to do so and the rest of us are free to ignore them.