- From: Ian Hickson <ian@hixie.ch>
- Date: Wed, 9 Aug 2006 02:51:49 +0000 (UTC)
- To: noah_mendelsohn@us.ibm.com
- Cc: Anne van Kesteren <annevk@opera.com>, www-tag@w3.org
On Tue, 8 Aug 2006 noah_mendelsohn@us.ibm.com wrote: > > I hope it's clear that my note wasn't questionning anyone's motives or > level of effort, least of all yours. Oh I didn't think you were questioning my motives, don't worry! I just thought I should give some background for my blog post lest people think I was just criticising from the sidelines or something. > I also think that the Web will be much better off if starting now, those > who deploy resource, and particularly those who deploy new media types, > new sorts of client side references (e.g. the next thing that plays the > role of <img>) try to learn from the TAG finding and do things "right". Yes, I agree that would be nice (to put it mildly). But why would it happen for future MIME types when it hasn't happened for the previous ones? It's not like using Content-Type is a new idea, or that people previously didn't realise that there were big problems if you ignored the file's labelled type. Say a new format comes along for describing 3D annotations to planetary models. Lots of people put up these files -- let's call them KML files for the sake of argument -- on their Web sites, in e-mails, on their file systems, etc. Many servers don't yet know about these "KML" files -- least of all the popular ones like Apache or IIS. Now, all the browsers just bail out when they see a "KML" file, saying "I don't know how to handle this kind of file!". Then one day, the browsers start supporting them. Half the files are mislabelled and don't work with these new browsers, the other half work fine. One day one vendor realises it can get a leg up on the other browser by making _all_ "KML" content work with their browser, instead of just making the correctly labelled subset work. Users start asking the second vendor why their browser doesn't work as well. How do you propose to stop vendors from competing with each other by making their user experience better? There is clear historical evidence that vendors will ignore standards when the standards get in the way of the user experience. Making them feel bad about breaking the specs doesn't stop this (believe me, I've tried). > At least then, we'll be able to gradually start getting the benefits of > server-side typing. The drawback of appearing to deprecate Content-Type > is that it misses the opportunity to send a strong admonition that, at > least starting here, we're going to try and do things right. I guess I thought that's what we were doing these last 16 years. I don't understand what the TAG finding says other than reaffirming something that has had nomative status since long before I looked at the Web. IMHO we're going to need something a heck of a lot more effective than a TAG finding to actually have any effect here. The biggest thing I'm worried about here, to be honest, is that every time we (the standards community) require the browser vendors to do something that they consider makes their user's life harder, they get one step closer to ignoring _all_ standards. That is, it's not just that they pick and choose the standards they want to comply to -- there comes a point where engineers decide that they've had enough of "stupid specs" in general, and ignore all of them. At that point, we (the standards community) might as well go home, because we are utterly powerless without the engineers listening to us and doing what we tell them to. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 9 August 2006 02:52:24 UTC