Dashboard HTML extensions for better or worse
I’m still making up my mind about posting my thoughts about all the new tiger features, but need at least a little more fact-checking beforehand. Yeah, tiger’s so yesterday by now, but i’m a slow thinking guy.
What really picked my interest recently is a mini-controverse about dashboard. No, not the whole dashboard vs. konfabulator thing, which i find kinda silly. Imho the dashboard concept is quite different from konfabulator, rather some kind of uberexpose meeting multiple-desktops-light than desktop widgets. It might kill konfabulator, but i don’t consider it a konfab rip-off.
This post is about the HTML-extensions introduced to empower dashboard widgets (or is it gadgets?). The first thing i read about this was by Todd Dominey, Dashboard: Apple‚Äôs ActiveX?, later i found Party Like It‚Äôs 1996! by Tim Bray. Not that i’m a web standards guru, but basically there was one point that really bothered me, a post by Dave Hyatt in which he introduces and explains the new search field. There he writes:
The search control will also even degrade gracefully in other browsers, since they won’t recognize the unknown type and so will just use a text field instead.
Nice that it “gracefully degrades”, but as i understand it, it also fucks up standards compliance and validity. Furthermore, degrading by leaving a browser clueless about what to do with an element isn’t all that graceful, is it?
By now Dave Hyatt already addressed Todd Domineys concerns and posted another followup “On Extending HTML”, both reasonable and refuting several concerns, but they still don’t totally convince me. The whole thing sounds a lot like it would encourage non-standards-compliant development.
He also writes in his second post linked above:
We have a phrase we like to use here on the Safari team, and that’s “real-world standards compliance.” What that means is that where possible we attempt to be fully compatible with the W3C standards, but we also want to support the real-world standards, i.e., extensions that for better or worse have become de facto standards.
and later in the same post:
In other words, in an ideal world where we had two years to craft Dashboard, maybe we could have used XHTML and SVG, but we aren’t living in that ideal world.
It’s certainly important to develop something useful fast enough to actually deploy it on a reasonable time scale. I just wonder where this leaves modern web standards – should they be ignored out of convenience, are they simply too heavy to be practically useful? Of course dashboard is a highly targeted and rather closed system, therefore general rules of web standards compliance don’t fully apply. But these proprietary extensions to webcore imho signal a lack of forward thinking in their implementation and i don’t think they belong in apples html render engine.
Overall dashboard feels a lot like a damn-ugly-hack putting on a pretty mask. My computing life could be so much easier if i didn’t care for the innards that keep my system running. I’m on the fence about how this turns out eventually.
Would you like to comment or share this post?
Tell me what you think on Twitter: Tweet
