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
seen this movie
Lots of email flew around, and Dave eventually seemed to
in to the idea of using
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
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
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
tell, you’ve done a
<MARQUEE> and invented new HTML
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
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.
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
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.