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

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

From: Tantek Celik <tantek@cs.stanford.edu>
Date: Wed, 22 May 2002 13:04:44 -0700
To: <www-tag@w3.org>
Message-ID: <B91147EB.C744%tantek@cs.stanford.edu>
From: "Simon St.Laurent" <simonstl@simonstl.com>
Date: 22 May 2002 12:03:21 -0400

> On Wed, 2002-05-22 at 11:52, Tantek =?ISO-8859-1?B?xw==?=elik wrote:
>> 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).
> 
> Uh, Tantek?  I think the XML community has little or no patience for the
> notion that the user-agent is supposed to fix errors made by the
> author.

I don't disagree, and I have personally lobbied for the various XML mime
types (text/xml, application/xml etc.) to be treated quite strictly.

But IMHO that has nothing to do with documents incorrectly served up as
text/plain.

> If I remember correctly, this draconian notion came from both
> Microsoft

Do you mean sniffing? That certainly predates Microsoft browsers.

Or do you mean the "incorrect and dangerous" comment in the TAG finding?  If
so, please reference me to the source you mention.

> (are you still at MS?)

Yes, I am still at Microsoft.

> and Netscape, who were tired of having
> to deal with such issues on a regular basis.

Certainly as an implementer I do not like spending my time coding to handle
bad content/configuration.  I would much rather be coding stricter
conformance, or additional features.

> However much it may pain the generous souls maintaining browsers, it's
> reasonably clear that such forgiveness isn't helping anyone,

I wish this were true.  Unfortunately such forgiveness is (still) helping
users access a portion of the web.

> and pretty
> much just encourages more bad behavior.

This is logically false.

Failing to encourage good behavior does not equate to encouraging bad
behavior.

On the other hand bad behavior by content authors / webmasters certainly
directly encourages bad behavior by implementers.

>> 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?
> 
> Typically the owners of a Web site would be smart to test their site in
> software which actually conforms to the rules specifying the technology
> used to create the site.

Agreed.

>> 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.
> 
> Which is perhaps why ALL UA's should be expected to enforce the rules
> equally lest bad behavior become a marketing point.

I don't see bad behavior as a marketing point.

As far as expecting all UAs to enforce the rules equally - I think I
understand your intent, but I would rephrase that as saying that new UAs
should strive to enforce the rules better than current UAs.  This is
precisely what we did with IE5/Mac, which was stricter in many ways than
previous versions of IE, which resulted in many authors complaining that
such strict behavior was buggy, which resulted in numerous individuals
coming to our defense.  Expect future versions of IE/Mac to be even stricter
still - but without breaking access to portions of the web.

Thanks,

Tantek
Received on Wednesday, 22 May 2002 16:00:15 UTC

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