- From: Sander Tekelenburg <st@isoc.nl>
- Date: Wed, 23 May 2007 04:05:26 +0200
Anne, you seem to mean to refer to Style Sheets's Content-Types only, but given some of the responses, and some other discussions about Content-Type, I take the liberty to interpret this as a more general argument against Content-Type. At 10:44 +0200 UTC, on 2007-05-22, Anne van Kesteren wrote: > For compatibility with the web it seems important to simply ignore > Content-Type in all modes. I'm confused about "in all modes" in this context. I thouht the idea was to do away with modes altogether? +++++ With Content-Type, one can serve HTML, CSS, PHP, etc. as text/plain. Useful to provide example code. I'm sure there are more use cases where there is no single correct interpretation other than the one the author specifies. Should we really make that impossible? With content-sniffing, users need fetch images even when they cannot see them, audio even when they cannot hear it. ["fetch" == wait for the data transfer, pay for the traffic, and wait for the content-sniffing parser to do its dance.] +++++ What about new types of content? It seems to me that relying in content-sniffing would mean that a new file format would have to be registered by browsers before they can do anything useful with it. With Content-Type OTOH, a browser can always be configured to do somethig useful (pass it on to an appropriate helper app) with a particular new file type. +++++ Some of today's browser vendors may be afraid to lose market share by respecting Content-Type, but tomorrow's new browser might be able to grab market-share by doing something useful with it. Let's be very careful throwing things away too easily. +++++ UAs can try to be clever, and content-sniff. But what about users? Over on WRI-Talk[1] we've got a discussion going about URL design[2]. The debate is whether <http://domain.example/blah.xyz> or <http://domain.example/blah> is more appropriate. The argument for using file name extensions is that they can provide a clue as to what sort of file is being pointed to, to help decide if it's worth the trouble fetching it, or *how* to fetch it. (For example, when you known in advance that alink points to a PDF, you might want to override your browser's default behaviour, end explicitly tell it to open that in a new window/tab, or save it to disk and/or open it in another application.) The argument against is that file name extensions aren't authorative (".php" might return a HTMl file, a CSS file, an image, etc.) and too confusing to many users. I see value in the second argument, but have my reservations, because it would mean hiding information also from those who would find it useful. (Come to think of it, if the tender souls of users need to be saved from this evil, why do UAs still expose users to URLs?) Still, I'm considering going for this (speccing it for the WRI[3]), but adding the provision that all links provide a MIME type through the type attribute (should be easy enough anyway, for authoring tools). Obviously that too isn't authorative, and most current UAs do nothing useful with this, but it can provide a useful hint to those who care or need that, and users can make the information visible through user CSS[4]. I admit I'm not entirely sure yet just how exactly this matters to the "giving up on Content-Type" idea. I just have a 'gut feeling' that it does. Let's imagine we manage to get a sizeable proportion of links on web pages to contain type attributes. (I don't believe that is far-fetched. More and more web pages are generated by authoring tools, and it shouldn't be that hard for such tools to provide type attributes with links.) In that scenario I can imagine UAs warning the user when, upon fetching a resource, its Content-Type doesn't match the link's type="" content. (They could do the same based upon content-sniffing, so perhaps this isn't a reat example...) [1] <http://lists.webrepair.org/mailman/listinfo/wri-talk> [2] <http://lists.webrepair.org/pipermail/wri-talk/2007-March/000011.html> and on [3] <http://webrepair.org/02strategy/02certification/01requirements.php> [4] <http://www.euronet.nl/~tekelenb/WWW/userfriendlierhyperlinks/> +++++ I do respect Ian's years of preaching to browser vendors. I've done some of that myself, often unsuccesfully, and know how frustrating it is. I'm not convinced though that this sort of experience is evidence enough to give up on something like Content-Type. Consider that a couple of years ago the browser situation was different than it is today. WHATWG, the HTML WG and the growing care for standards-compliancy in general are evidence that unforeseen changes can make what once seamed like a lost cause into a possibility again that many are willing to invest in. True, it can be realistic to give up on a fight. But it can be equaly realistic to continue it. Environment variables tend to change, which can make the seemingly impossble possible -- unless you've cosed the door. -- Sander Tekelenburg The Web Repair Initiative: <http://webrepair.org/>
Received on Tuesday, 22 May 2007 19:05:26 UTC