W3C home > Mailing lists > Public > www-tag@w3.org > May 2002

Re: Proposed TAG Finding: Internet Media Type registration, consistency of use

From: Tantek Çelik <tantek@cs.stanford.edu>
Date: Wed, 22 May 2002 10:57:44 -0700
To: Rob Lanphier <robla@real.com>
Cc: "www-tag@w3.org" <www-tag@w3.org>
Message-id: <B9112A27.C727%tantek@cs.stanford.edu>
On 5/22/02 9:11 AM, "Rob Lanphier" <robla@real.com> wrote:

> On Wed, 22 May 2002, Tantek Çelik wrote:
>>> http://www.w3.org/2001/tag/2002/0129-mime
>> 
>> Interesting if not a bit humorous (unintentionally I'm sure).
>> 
>> This was my favorite part:
>> 
>>   "An example of incorrect and dangerous behavior is a user-agent that reads
>> some part of the body of a response and decides to treat it as HTML based on
>> its containing a <!DOCTYPE declaration or <title> tag, when it was served as
>> text/plain or some other non-HTML type."
>> 
>> Incorrect and dangerous?
>> 
>> While it is a laudable goal to avoid and/or limit sniffing when at all
>> possible, unsubstantiated comments like these are inflammatory at best, and
>> horribly naive at worst - given how many HTML (.html etc.) pages are still
>> served as text/plain. (Nevermind GIFs and other images served as
>> text/plain).
> 
> ...and a number of SMIL documents that are marked as "application/smil"
> that have <head> tags in them.  Older versions of certain browsers
> incorrectly try to parse these documents as HTML.

application/smil would have been a much better example than text/plain.

> Second guessing behavior, while useful for entrenched companies to
> reenforce dependencies on implementation quirks, has effects
> that are deleterious to the long-term health of the web.

This is nonsense.

There is nothing stopping web servers from fixing their configuration files
etc. to return proper mime types.

Unfortunately the reinforcement goes in the opposite direction that you
speak - the content/types can be changed to be correct, and will look fine
in today's browsers, however, if today's browsers changed in this way, they
would look broken.

Logically therefore the TAG should first provide strong wording for web
sites and web authors (i.e. fix your content and configuration files
please), rather than browbeat implementers into breaking portions of the
web.

>> My second favorite part:
>> 
>>   "Web software SHOULD NOT attempt to recover from such errors by guessing,
>> but SHOULD report the error to the user to allow intelligent corrective
>> action."
>> 
>> Typically a user of a web site does not have the ability to correct the
>> website itself.  Nevermind perform an "intelligent corrective action".
>> Which usability genius decided that it was a good idea to report errors to
>> the user that are meaningless to the typical user (typical user has zero
>> knowledge about mime types) and the user has no chance of fixing?
>> 
>> If a UA did report such errors with a web site, the typical user would take
>> the corrective action they usually take when errors are reported from a
>> website, and that is to try a different UA.
> 
> Generally speaking, when my software tries to outsmart me, it usually
> fails. I've taken to avoiding software which does try to outsmart me.
> I'm probably not the typical web user, but still, too much "do what I
> mean, not what I say" engineering can backfire.

The software is not trying to outsmart you the user.  It is trying to
outsmart the dumbly configured web servers and content out there.

Tantek
Received on Wednesday, 22 May 2002 13:52:45 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:32:31 UTC