[whatwg] Content-Type (was Style sheet loading and parsing (over HTTP))

[Sander Tekelenburg]

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/>