Extended Dash
Published 19 years, 9 months past
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.
Comments (10)
Pingback ::
Hixie's Natural Log: Extending HTML
[…] There are other problems with DOCTYPEs. Eric unintentionally
reminded me of one when he said:
IBM
already does something like this, having created an “IBM XHTML 1.1 […]
This is a possible suggestion for Dave – there’s no version number in his proposed identifier. Maybe it’d be safer to have one.
The notion that XML namespaces are too difficult for the average HTML coder is hyperbole, if you ask me. Namespaces are vital in any language/environment that allows for reuse and extension (think: Java packages).
However, given that any conceivable implementation will most likely be built using a DTD, there is little utility in using namespaces. DTDs are namespace-agnostic by design. Pseudo-namespaces can be fudged by creating elements with semi-colons in their names.
My advice would be to move toward an XML Schema to define gadgets. A custom schema would allow Apple engineers to create a lean and mean HTML-like vocabulary, without the vagaries of any current X/HTML implementations. The rendering engine that would consume these XML instances could be significantly simplified from the current “what would Netscape 4 do?” methodology. More importantly, however, schemas can be built for reuse, meaning that you or I could design our own sub-vocabularies by extension or composition of the base Apple vocabulary.
Dashboard is an amazing opportunity to move toward a better world with truly extensible and reusable components where there’s no such thing as “quirks mode”. Apple must take some leadership, rather than undermining the progress toward standards we have already made.
I think the idea of using a new
DOCTYPEis quite good, but I completely disagree when the purpose is to extend the language with presentational elements and attributes.<canvas>is quite clearly presentational. Why couldn’t they use<object>to include a pre-written applet or other control that can do exactly what canvas is supposed to, or if not, then it should definately be included with a seperate namespace in a XHTML or other XML document. As for thecompisiteattribute for the<img/>element, I can only assume it’s something presentational that should definately go into a stylesheet, such as CSS. Although, I don’t particularly like proprietary CSS extensions, they’re better than HTML because they don’t pollute the markup, so they could always add it with their user agent prefix. eg.-safari-composite: whatever;(or whatever their prefix is).If Microsoft and Netscape had done what you are suggesting Safari do by creating a new
DOCTYPE, where would we be now? We’d have millions of websites using MSIEML or NSML, and neither docuement would work well in the other browser, because of all the extra presentational elements and attributes that we may have ended up with (in addition to the ones we already have). Whether this would be better or worse than the current sitution we’re in (ie. most sites either don’t use a doctype, or many of those that do don’t validate against it) is debatable, but I think it would be worse because it would further encourage authors into believing that using presentational markup was acceptable.I stand by what I said in my recent blog posting, Exploring Safari’s
HTMLTag-Soup Extensions, in that the Safari team should hang their heads in shame over these extensions. However, if they were semantic extensions that actually contributed to the structure of the widget, then I might not be so against them, it’s just that they’re clearly presentational, and thus should not be included in a semantic language.Trackback ::
ubiquitous minghong - My Blogger
Please extend the web correctly
Dave Hyatt is an open person who listens to comments. But unfortunately he seems to misunderstood the suggestions.
On his previous blog post, he mentioned 2 ways to extend the (X)HTML:
* Namespace mechanism
* New DOCTYPE declaration
…
From the XML point of view, re-namespacing the entire XHTML vocabulary seems like a bigger compatibility issue, since a namespace aware XML processor should treat “http://www.w3.org/1999/xhtml h1” elements as being distinct from “http://www.apple.com/2004/xhtml-extended/ h1” elements, for instance. So rather than just creating a small number of new element types, we have a whole host of new ones.
I know that he says that in an XHTML document you’d define an “apple” namespace prefix and only use it for <apple:canvas> elements and similar, but if Safari recognises all the other elements under this namespace, we could end up with pages on the web that display okay on Safari, but are unformatted on other browsers because it appears to be in a different XML dialect.
From the HTML perspective, it doesn’t seem like such a big deal, since the namespace declaration will simply be ignored. And if a future HTML spec is incompatible with these extensions, it provides a way to tell what the author intended.
Trackback ::
Lachy's Log
Safari’s Pseudo-Solution
Seriously, what is the point of adding it to HTML? Why not just do it correctly with XHTML? The Safari team should just go all the way, and implement these extensions purely as an XHTML module… this is a quick fix to address recent concerns, which ju…
Trackback ::
The Web Kit
Extending HTML
As a Mac user, I’ve been closely following news concerning the state of web browsers on the Macintosh platform, and particularly news concerning my two favorite browsers, Safari and OmniWeb. Like a number of other web enthusiasts, I was concerned…
These two statements seem contradictory. If they don’t intend to use XHTML in Dashboard widgets, shouldn’t they use “http://www.apple.com/2004/html-extended/”? I understand that the namespace URI doesn’t point to an actual document, but all the more reason to correct this now, right?
Pingback ::
Lachy’s Log » Blog Archive » Hixie’s Ruling and Composite Attribute
[…] hat a new DOCTYPE is not a good solution unless it were confined only to the dashboard. As I commented on for one of Eric Meyer’s posts, if Microsoft and […]