Extended Dash
Published 14 years, 3 months ago
It’s been interesting to see the back-and-forth over Dashboard the past few days. Dave‘s posts have been greatly illuminating, and I belatedly discovered Tim Bray‘s initial reaction and further thoughts on the topic. Dave has now done a test implementation of adding a default namespace for Dashboard widgets, using the namespace URI http://www.apple.com/2004/xhtml-extended/. That doesn’t (yet?) point to an actual document, but that’s okay; URIs don’t have to refer to a specific resource. They just have to be unique. This is in contrast to URLs, which in theory have to point to something that actually exists. Although clearly reality has a long way to go before it catches up with that theory.
As Dave points out, his approach not only makes it possible for HTML to be extended without breaking with existing standards, it also provides a handy “pay attention to the Dashboard stuff” trigger and it opens a clear path toward supporting XML-based widgets in the future. This is all kinds of cool, and I can’t see any real drawbacks. If you do, let Dave know, or comment on this post; I’ll collect them (since Dave doesn’t presently have commenting on his site) for his review.
Despite it being Dave’s second choice, the “create a new DOCTYPE” idea is something I want to discuss in a little more detail, if only to illustrate how it can work. Here’s a markup example of an amazingly stupid and useless widget using a hypothetical DashboardML DTD.
<!DOCTYPE html SYSTEM
"http://www.apple.com/dtd/2004/dashboardml-10.dtd">
<html>
<head>
<title>myWidget</title>
<style type="text/css">
body {background: aquamarine;}
</style>
<script type="text/javascript">
function startup() {
alert('Happy! Joy!');
}
</script>
</head>
<body onload="startup();">
<canvas blah="foo" yadda="baz">
<h1>Widget!</h1>
<div class="main">
<p>So cool.</p>
<p>So fine.</p>
</div>
<img src="yar.gif" composite="punchout" alt="Yar!">
<p id="footer">copyleft nobody</p>
</body>
</html>
By referring to a DTD defining a language that looks just like HTML except for the canvas element and composite attribute, along with any other additions, the markup stays free of explicit namespacing and works the way authors already expect. It really is that simple. IBM already does something like this, having created an “IBM XHTML 1.1 Transitional” DTD that’s used throughout their Web presence. The comments at the top of the DTD file explain how it’s different than regular old XHTML, but the executive summary is that it permits some old table-and-spacer-era markup hacks in an XHTML environment. If you run an IBM-XHTML compliant document through a validator that loads and uses IBM’s DTD to check over the document’s markup, then the document will validate. The same thing could be done for Dashboard—or for any other project, really. That’s the beauty of it. We aren’t constrained to HTML any more, nor even to XHTML. We’re only constrained by what clients will support… as always.
(It was pointed out to me via e-mail that XHTML is perfect for this, because it’s already modularized so all you have to do is tack on another module. That would be quite true, except for Dave’s statement that the Dashboard widgets won’t be using XHTML.)
The other potential problem with my suggestion, according to Dave, is that the DOCTYPE is used to pick a rendering mode in current browsers. Dave says he doesn’t want to restrict widget authors to one mode or the other. Now, I’d personally have no problem forcing all widgets to be rendered in standards mode, but that’s probably just my inner purist talking. If it were important to allow quirks mode, then create a transitional DashboardML DOCTYPE that triggers it; use the default (above) for triggering standards mode. This would be consistent with current DOCTYPE switching schemes.
Regardless, at this point, I think we’re pretty well assured that things are headed in the right direction. That’s very much thanks to Dave’s openness and genuine interest in doing the right thing, not to mention his swift response times. Where things go from here, we’ll see, both at Surfin’ Safari and (I expect) by way of submissions to and work by the WHAT WG—which itself will be the subject of a post in the near future.