Now we know more about Dashboard, and according to Dave, the widgets are indeed HTML, not XML. Fortunately, hastily-applied bandages kept my ruptured vein from killing me. As for my TiBook, some quick squeegee work saved the display, but now the keys are kind of sticky. How’s that for an image?
As most people who know me are aware, I’m very much a real-world kind of guy. That side of me is in favor of what’s being done to make Safari and the Dashboard more useful. The additions to HTML and the DOM are indeed minimal—so far. I’m sure the first few proprietary extensions to IE/Win were minimal, too. After all, it’s just a tag called MARQUEE. What’s one more element?
I also recognize that HTML is far too limited for anything except simple document structuring. It doesn’t have interesting controls like sliders, and it certainly doesn’t provide any joy for people who want irregular shapes. SVG does provide such things, but Dave’s point about it being a huge task to implement is understandable. If only Quartz had been based on SVG instead of another technology… but there’s no sense crying about spilled milk under the bridge now, I suppose.
Of course, the theorist in me is quivering in outrage. The browser-wars veteran isn’t too thrilled either. For years, we heard Microsoft and Netscape say things like “standards are secondary to customer demands” and “standards aren’t as useful as the cool new proprietary features we’re adding”. These things need not be inimical to standards support. They should not require a breaking of standards.
As I observed previously, making Dashboard widgets be XML would solve the problem, or at least could fairly easily. Dave says that won’t happen:
…it was suggested that the widgets be written in XML rather than HTML and that all of the new tags and attributes be namespaced. However, this would have dramatically increased the complexity of crafting Dashboard widgets. People know how to write HTML, but most of those same people have never written an XML file, and namespaces are a point of confusion.
I agree about namespaces being confusing; the only reason I have any comfort level with them is because we had to define multiple namespaces for the XML format we used on DevEdge, and I made enough mistakes using them that I eventually came to understand them. Sort of. To an author who’s only ever seen HTML or even XHTML, they would likely be very annoying. I’d like to point out, though, that I suggested not namespacing everything, but creating a whole new DashboardML that used a whole bunch of elements that looked and acted the same as XHTML, with whatever additions were needed. Thus the beginning of the document (after the DOCTYPE) might look something like this:
<html xmlns="http://www.apple.com/2004/dashboardml">
<head>
<title>This is an example</title>
</head>
So instead of pointing to the XHTML namespace URI, you point to the DashboardML namespace URI. The end result is that you can have a document that looks exactly like XHTML, except for the additions (composite and so on). It seems like it would be fairly simple to do, but again, I can’t say that with any authority.
So let’s assume that, for whatever reason, the above approach isn’t possible within the Tiger timeframe. There is another way, one I mentioned briefly in my last post. That would be to create a new DTD for DashboardML, one that’s a direct copy of the HTML 4.01 DTD with the needed additions. It could look like this:
<!DOCTYPE html SYSTEM "http://www.apple.com/dtd/2004/dashboardml-10.dtd">
That would point to a DTD that defines DashboardML. DashboardML would be exactly like HTML 4.01 (or whatever version they wanted) in every respect except for the additions of the canvas element and the composite attribute. The advantage is that they can add more things if needed, and not pollute the HTML space. Since Apple’s working with the WHAT WG to get these things accepted, then perhaps the WHAT WG should host the DTD. Then it might look something like:
<!DOCTYPE html SYSTEM "http://www.whatwg.org/dtd/2004/whatml-10.dtd">
The URI could be anything, so long as it pointed to an actual DTD. I don’t even care where it lives, so long as it lives somewhere. I should also point out that this would need to be done even if the widgets were XML, as opposed to an HTML-like language. Either way, they keep Dashboard extensions out of the HTML space.
Why should we even bother? One word: validation. By providing a DTD that defines the markup language being used to create the widgets, validation becomes a snap. That’s important, because with validation, widget authors can keep their markup clean. It will help them with their development efforts.
Here’s another reason to bother: reducing confusion. “But Eric, a new DOCTYPE will increase confusion!” you might be thinking. Maybe at first, although overall I doubt it will. The confusion-reducing aspect is that when widgets get published on the Web—and they will be published on the Web—there will be an obvious indication that the markup is not traditional HTML, but something really close to it. Browsers can then do what they’ve always done: handle what they understand, and ignore what they don’t.
It’s been argued that Dashboard widgets are intended for a closed environment, and not to sit out on the Web. True, but that won’t change anything. Within a week of their appearing in the WWDC build of Tiger, Dashboard widgets appeared on the public Web (they’ve since been pulled offline). This won’t exactly tail off as more widgets are built. If anything, we’ll see more and more widgets getting out into the wild—for example, when people find a widget they like and adapt it for use on their public sites. The calendar is the most obvious example that comes to mind. In order to keep things straight, widgets need to have their own DOCTYPE. If nothing else, it will provide a convenient explanation when someone throws a widget onto their site and it breaks in other browsers. (“Yeah, see, that uses DashboardML and only Safari supports it…”)
Over at the WaSP, Anders Pearson wrote:
Overall, though, it’s not that big a deal. Safari does an excellent (not perfect) job of supporting the various HTML, XHTML, and CSS specs as they’re written and ultimately, that’s what’s most important. If developers don’t want to use the extensions, they don’t have to.
As long as these extensions happen within a new document type, then I agree. Allowing them to operate within any document bearing a W3C DOCTYPE would be a big, big mistake.
As Apple says: