Dashboard Again
Published 19 years, 9 months pastTo 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.
Comments (18)
Eric, I think your comments are plick (another made up word, it’s a good thing). I thought the same thing about the
statement.
I see XML as the most poluting language on the net… if it is considered to be a presentation language… but that’s what XSLT, CSS and XHTML are for. Markup your document how you want… if it’s in XML you can transform, translate and otherwise manipulate it in a nice standardized way: the W3C said so.
Actually, you’re disagreement is entirely relevant. Your status as an expert in this field, imho, also gives you credibitlity when it comes to knowing the audience that can design Dashboard apps. What their skillset is. The bar Apple has set is entirely too low (not from using HTML, but from expecting that people who can make Dashboard gagdets wouldn’t get XHTML), and they should seriously consider making XHTML the baseline, not HTML. If that decision then trickles into fixing this whole mess, we will all be better for it.
In that regard, in my opinion, you should not discount or lessen your point-of-view on this topic.
If the mess of including hypertext in RSS is any indication, I don’t think it’s all that fair to say that the semantics defined by RSS have at all been agreed-upon—at least not to any acceptably reliable degree.
(not to mention the splitting of RSS into various flavours…)
I honestly don’t see why there is the requirement to use HTML. What can the semantics of <blockquote>, <p>, etc bring to developers when developing desktop widgets? I really can’t see the value. It doesn’t make things easier for developers, as virtually none of the existing element types apply to desktop widgets. It only pollutes existing usage of HTML. Why is HTML so applicable, and a new XML application so inapplicable? Dave Hyatt hasn’t explained this to us, which is why it is so hard to accept.
I also think that a major case of double standards is in effect here. If Microsoft were introducing new element types and trying to pollute HTML with them, everyone would be up in arms about it. But because it’s the “underdog”, everyone seems to be turning a blind eye. It’s not about who implements it, it’s the technology that matters!
Actually, Jim, I’d be saying the same things in the same way if Microsoft had similar plans. This is about as “up in arms” as I get. Since MS is using XML (or something very much like it) for XAML, Avalon, and the rest of Longhorn, I don’t have a lot to say about them. It’s all XML, so they’re free to do as they please so long as it’s well-formed. I feel the same way about Apple and the Dashboard, which is why I said something in the first place. Maybe four lengthy posts in a week constitutes a blind eye to you, but not to me. That’s time I could have spent playing with my daughter!
Amen! I don’t know enough about XML, DOCTYPE, or namespacing to either agree or disagree with your proposals, Eric, but your efforts to clarify these issued for the rest of us are always appreciated.
Sorry Eric, I wasn’t specifically referring to you when I mentioned the double standards. It just seems that a couple of people brought up the issue, Dave Hyatt responded with “hey, we’re trying to advance the web”, and people just went “oh, that’s alright then, do what you must”.
It’s frustrating when nobody seems to be bringing up the pertinent point of “why HTML?” Widgets being shown on a desktop seem to have very little in common with hypertext documents. What does HTML bring to the table? The experience developers have with <h1>, <cite>, etc seems to have zero relevence to building desktop widgets.
Even if there were some relevence, what happens in the next iteration? It’s one element type now, but what happens when Apple decides that an extra couple of element types are needed? Will we end up with lots of documents that are sort-of-HTML-with-a-lot-of-Apple-element-types-in? It really seems to stink of the old browser wars, but most people don’t seem to want to say it directly for fear of offending somebody “on our side”, as opposed to the Microsoft camp. The front page of webstandards.org mentions that some people have concerns, but concludes “Overall, though, it’s not that big a deal.” What a joke, coming from an organisation that claims to promote the use of standards!
In defense of the decision to use HTML over XHTML, from Hyatt himself:
Don’t get me wrong–I’m all for XHTML, but this is a matter of practicality. When a user sees a Dashboard widget, he doesn’t care (or even notice) if it’s built with state-of-the-art markup. He does notice if it’s slow and buggy.
Also, I’m entirely confident that Apple will make every effort to make their extensions part of the standards–standards are Apple’s friend on the web, and they’d be wise to drum up support for these new (cool) features among other up-and-coming browser vendors. Ben Hammersley has recently written that the browser wars are about to begin again, and this time, maybe it’ll be Apple, Mozilla, and Opera touting support for cool new standards–not Microsoft and IE 3.
From a Windows user that wished he had a Mac:
I’m wondering if the Dashboard app could/will be/considered for/be ported to the Windows desktop. I’m assuming it would be, considering its core language: it wouldn’t seem to be that hard if it were in HTML/XHTML/XML. If it were standards-based, as Eric would like it to be, then porting it would be easier.
If not, it just may make the job for those of us about to switch platforms thatbend over backwards to make it simpler, not harder, like any other company that is working hard for my business, be it an insurance company, investment broker — whatever (and I’m really picky about my investment broker!).
Eric, I know you’d rather play with your daughter; I would, too. But (sorry for beginning a sentence with “but”) your input is essential to the resolution of this argument. Please: keep it up!
Ooooops! Something happened, and it dropped part of my comment. I apologize for the confusion; I probably missed a closing tag…
My point was that if Dashboard is not standards-based, it might make switching platforms that much harder for folks like me. considering Apple’s great investment in the “Switch” advertising campaign, you’d think that they’d bend over backwards to make switching simpler, not harder, like any other company that is working hard for my business… (You know the rest; thanks for the repost!)
I’m sorry but i’m getting sick and tired of people bitching about this Pink is so entirely right about this and people really need a reality check.
Really Eric, i think this is all just coming down to wasted deliberation, Apple/Hyatt’s can’t please everyone and i think the namespace solution is the perfect one semantics aside. Really, people need to stop getting so worked up about this, at first i was glad to see people stand up, and i still am, but now that he’s looking into solutions and taking in feedback i think it’s on the right path.
What i’d really like to see is some entires on what people are going to do with it, i can’t wait to see what you and Zeldman and others come up with.
Oh and is anyone else suprised he hasn’t chimed in on dashboard at all yet?
oh btw Eric, i don’t want you to take any of that wrong, you’re not the person i’m annoyed with, it’s the everyone else that keep complaining about it and arguing bitter irrational semantics over namespaces, xml and keep comparing this to the browser wars and freak out even after hyatt started to open up to better solutions.
Where exactly is “everybody bitching about this” and why didn’t they do so before it got to a point where _they_ needed a “reality check”?
When the WHAT decided to launch a new HTML dialect in the face of a module-based XHTML variant, I thought I had them figured out. If we cannot work with the coolest browser A, let’s have a retro movement that will give browser B and C time to catch up. Make it digestible below the level of abstraction needed to understand the concept of a namespace and call it “power to the people”. Claim further support from radical advocates of prominence in public forums by denouncing official working groups. Invent the wheel _without_ scripting technologies to make it innovative and glamourous. All in all, a sensible strategy for promoting browsers with inadequate XML support. But things are going downhill rather fast from here. So, who get’s to be the default namespace? We can put our companys name in the namespace and claim all of HTML for ourselves or we can forget about namespaces alltogether and leave the problem for future generations to solve. We can entertain the idea of a new HTML doctype with no restrictions to future tags and if we hurry, we can invent the canvas tag before the next guy. Forget that XML and namespaces are intended to deal with this very situation, they are far too complex for the human mind to comprehend. There may be an explosive growth in Firefox extensions using XML, XBL, XHTML, RDF and custom namespaces, but kids nowadays would rather trust extension authors that aren’t quite clever enough to prefix their tags. With all the “technical hurdles to the use of XML” in modern browsers, we’re simply better off using HTML instead of any old XUL rendering engine. Somehow it appears to me that these guys aren’t battling Microsoft – with recent developments, they even appear to be battling eachother. Not the browser war I’d hoped for, but oh! Don’t mention the war, right? I’ve lost focus on these developments, but one thing seems increasingly clear: If browser technology B and C had a working XML rendering engine with namespace support _none_ of this would even be an issue. It would be a trivial task! And namespace aware specifications such as XHTML, XHTML2, SVG, XBL2, XSLT, Xforms would _still_ be hip with the happening people. Enough “bitter irrational semantics over namespaces” already, but hey.
I agree with everything you just said, especially your response to Hixie’s assertion that XML should never ever be used on the internet for something that doesn’t already exist. Given that Dashboard is happening, and Apple is doing their best to make it as easy as possible, I think Dave Hyatt has been quite flexible on this whole issue.
Mr. Zeldman hasn’t commented because… well… he’s… his mind is… his wife… here.
my point is… just what pink said, this isn’t for the web, no one’s going to use it on the web and as far as it concerns Hyatt/Apple don’t really need to do anything about it, it’s not going to be another Marquee, it’s not going to break up the standardization efforts, it’s not going to cause mass chaos and make people’s heads explode.
Dashboard needs to be as easy as possible, that is one of apple’s goals, most web designers have no idea about namespaces and doctypes sadly, and really it doesn’t matter because this doesn’t have anything to do with the general internet, it’s apple using existing technology in a different way on the local level. The programs can use Cocoa programming too, and ::gasp:: other browsers/platforms don’t support that. “APPLE IS DESTROYING THE WEB!!111!!” Give me a break, this isn’t for the general internet, no one will use it for the general internet and it’s not a concern, anything Dave/Apple does to appease people is more than gratious of them. And on top of that, any of this that is going to be used on the web is being submitted for WHAT so that they can be ratified and used.
Also, yes reality check… Dashboard is not out, it’s not here now, and there is plenty of time for things to be refined, implemented and smoothed. It just seems to me that every blog I read has someone ranting and raving about how evil this is, and how none of Dave’s solutions are good enough and whatnot when really… in the grand scheme of things… none of it matters. Take a step back people, stop being idealogical fundamentalists and look at what’s going on, sure in concept it’s something to freak out and get up in arms about, but in reality it’s not going to do any harm whatsoever.
I’ve seen many people comparing this to the browser wars, marquee etc but no one is talking about what real damage this could cause… because there isn’t any, and people need to sit back and realise that.