Dashboard Again
To paraphrase Tim Bray, I had thought I’d said enough about the Dashboard and its markup, but when Dave Hyatt says he’s interested in hearing your thoughts, out loud you think. Dave’s interest in my thoughts was sparked by Ian Hickson’s post about extending HTML, where he raised objections to all the technical proposals made thus far and advocated working with the WHAT WG before adding anything new. So let me first establish my baseline for my thinking on the subject, both past and present:
Dashboard will happen, and will be present in Tiger, and will have at least the features described thus far. All that remains is to advocate for interoperability with standards.
That isn’t some sort of admission of defeat: I’m really looking forward to the Dashboard. I think it’s a great thing. I think it shows how, with just a little bit of extension, the standards we already know can be used in compelling and useful ways, and for that matter how standards can yield powerful applications on their own. The baseline assumption I make above is a way of establishing the parameters for my discussions of the subject. It helps keep me focused.
In order to keep things clean, I proposed an approach centering around a new DOCTYPE, and Tim Bray proposed another revolving around namespacing. Ian pointed out the technical flaws in all of our suggestions. Strictly speaking, Ian’s right: there are technical problems with each of the proposed solutions. In the world of pragmatic standards, though, what’s important is making things work as necessary to get the job done. Thus my approach. You haven’t heard me complain about the addition of contenteditable to the Web Core’s DOM, for example. Why would I? Dave’s right to add it.
It seems that both Tim and Ian felt that creating a new DOCTYPE was a poor idea; one reason was that it would mean recreating the entirety of HTML in DashboardML, with elements bearing the same name and given (presumably) the same semantics. I don’t really see why that’s a problem, since it’s already been done once before, for a little number we call XHTML. Now, it might very well be a better idea to create WHATML instead of DashboardML. That’s fine with me; in fact, I mentioned that as a possibility in my proposal. The actual name and home of the new language doesn’t much matter to me, although I should point out that whoever is responsible for the new language, it’s going to require either a new DOCTYPE or some kind of namespacing solution. If Apple’s additions can be accepted by the WHAT WG in time to get Dashboard shipped with Tiger, then great. If not, they’ll have to move ahead without that imprimatur. My goal is to advocate that they do so in a standards-friendly way.
In response to my comment that I thought Dashboard would be better off as XML instead of HTML, because that way you can make up whatever markup is needed, Ian said:
So let me get this right. It’s ok to send proprietary non-standard markup over the Web, so long as the angle brackets are XML angle brackets and not HTML angle brackets?
In a word, yes. That’s what the W3C has been telling us for a while now, so why would I think otherwise? Sure, the W3C publishes new stuff using XML and it’s all been thoroughly vetted and worked over and generally committeed to death, and that’s great. But XML makes it possible to invent any markup language you like. So far as I can tell, that’s kind of its point. As long as things are well-formed, you’re good; if you’re both well-formed and valid, then angels descend from the markup heavens to sing your praises.
HTML is a well-defined, long-understood (almost-)SGML application. Changing it willy-nilly is like making up new words to add to English. (Hey, did you see that roopyrastic article in last month’s Scientific American?) On the other hand, if you create a new XML language, then you’ve gone the Esperanto route. The language is as valid as you say it is, and it is a whole new thing, but at least you’re not polluting an existing language with stuff you made up.
So with XML, anyone can make up anything and release it into the wild. It might be argued that to send new XML languages flying around the public Web is a technological rebirth of the Tower of Babel, to which I would respond, “What else did you think was going to happen?” In fact, it’s been happening for a while, as the widespread use of RSS will attest. I haven’t noticed that being a major problem for anyone, and in fact you can combine RSS and CSS to display them in a browser. That doesn’t seem to be a problem either.
Besides, all of the XML-centric solutions, flawed or not, were excluded by Dave from the outset when he said that Dashboard widgets needed to be HTML, not XML. The reason given was to lower the entry barrier for would-be widget developers. I personally don’t agree with that perspective, as I believe anyone skilled enough to create a decent widget will find XHTML (or even namespacing) syntax the least of their concerns. My disagreement isn’t terribly relevant, though, since I’m not the one defining the way Dashboard widgets work.
As for the concern that adding new stuff to HTML will leave it free of semantics and confuse everyone, I don’t accept that at all. The semantics that exist in HTML, XHML, and so on exist because we’ve collectively agreed on what they mean. I don’t mean that we all held a big convention and voted on the meaning of h2. The HTML specification defined what h2 means semantically, and the rest of us (authors, editors, search engines, etc.) tacitly agreed to go along with that definition. The same thing can happen again—and, in RSS, already has. RSS defines its own semantics, and everyone’s agreed to go along with its definitions. It helps that the elements are given obvious names like description, of course. RSS also has a title element for every entry in the feed. Yet nobody, so far as I know, has gotten those title elements confused with HTML’s title element.
So now what? Now the team at Apple keeps pushing forward to make Dashboard the best product it can be while still making it as easy to develop for as possible. Fortunately, Dave is willing to publicly discuss how that will be accomplished, which is nothing short of amazing (although totally in keeping with what I know of Dave). He has also said Apple is willing to submit their additions to the WHAT WG for discussion. I honestly don’t know what more one could ask for at this juncture. There is every opportunity to work with Apple (rather than protesting against it) to make sure that Dashboard widgets interoperate with the Web’s foundations… or at least don’t cause unnecessary problems. Apple is listening. It’s up to us to talk with them, understanding their needs and limitations while making clear our concerns and suggestions.
Despite my complete lack of time and reluctance to add still more mail to my bulging Inbox, I may well have to subscribe to the WHAT WG public mailing list.
