Extending HTML, Again

I had thought I’d said enough on this subject, but when Dave Hyatt tells you to speak up, up you speak. Summary: Dave’s latest approach for his new widgets is OK but a little clumsy, and I don’t quite get why Hixie prefers dashes to colons.

The Hyatt Hack · What Dave wants to do is introduce new elements, for example <canvas>; initially for his Dashboard product, but it sounds like something you might sensibly want in a future version of HTML. Some people, including me, grumbled at Apple just unilaterally making up new elements (we’d seen this movie before).

Lots of email flew around, and Dave eventually seemed to buy in to the idea of using semi-pseudo namespaces. I thought this meant that he’d require something like xmlns:apple="http://www.apple.com/2004/xhtml-extended/" on the root element and then use <apple:dashboard>. Of course it wouldn’t really be a namespace when it was being used in HTML, but it would be an OK tag name and wouldn’t cause any software heartburn. And when it was in XHTML, it would really be a namespace and everything would be fine.

What Dave did was turn the whole thing around; you put xmlns="http://www.apple.com/2004/xhtml-extended/" on your root element (see, no :apple), so all your tags magically become members of new namespace. Thus, you can just stick <canvas> in the middle of your code and everything’s fine.

Well, OK, I guess, except for:

• This is only really clean when you’re in XML; as far as HTML software can tell, you’ve done a <MARQUEE> and invented new HTML tags.

• Apple has invented a couple of hundred new elements, namely all the XHTML elements, only in the Apple namespace. Uh, I assume they’re defined to have exactly the same semantics as the XHTML versions? Seems kind of unwieldy.

• Now, suppose I want to serve some of this Apple-extended XHTML across the Web. That means I have to send it along with a header to say what the Media Type is.

  If I send it as text/html, well, it’s no longer valid with <canvas> in there and any validator will puke on it. (Good Web designers hate puking validators.) If I send it as application/xhtml+xml, it’s completely borked because software that’s expecting a web page is going to have no idea how to deal with all these elements in this weird Apple namespace. And if I register my own Media Type, say application/apple-xhtml+xml, and send it that way, it’s still borked because no software out there (aside from Safari) will know that Media Type

And I’d note with respect that if you did it the other way round, i.e. just put the <canvas> element in the Apple namespace, all these problems would just dry up.

Finally, as I’ve noted before, the semi-pseudo-namespace trick has been done before, by Microsoft, and in practice has proven to work just fine.

But having said that, this proposal is at some level cleaner than just unilaterally cramming your own new tags into HTML.

Hixie · Everyone who knows browser politics (but that’s not everyone) knows that Hixie is Ian Hickson; he’s a leading light over in the WHAT WG.

He was extremely unimpressed with pretty well all of the alternatives Dave Hyatt considered for Safari (snicker, he’s got some reasons to dislike Dave’s latest that I hadn’t thought of).

Also, he and Dave have some interesting back-and-forth on the politics of how to move proposals around.

Anyhow, he ends up suggesting that instead of namespaces or even semi-pseudo-namespaces, Apple go with something like <apple-canvas>. I could live with this, but I don’t really see any advantages over <apple:canvas>; both are equally opaque to HTML-savvy software, and the colon and dash are equally OK as name characters. But I see one important disadvantage; it doesn’t morph into a real XML namespace when seen through XHTML’s eyes. I could certainly live with it. But for now I think the best thing for Apple and the Web would be the mainstream thing, the prior-art thing; grab a namespace and use it as a sandbox for building your own elements.

---