RE: Document sniffing for type information

At 09:19 AM 2002-12-03, Jon Hanna wrote:

> > What I am objecting to in the TAG finding is the idea that "thou
> > shalt not" offer the user a guess when the indicated type clearly
> > fails to match the content.
>
>The example that started this discussion wasn't an example of this. A text
>document which could be a valid HTML document with a MIME change is still a
>text file. Browsers failing to treat it as a text file cause all manner of
>problems (IE's MIME behaviour can often be quite bizarre indeed).

Agreed.

>If the type completely fails to match the content then you have an error.
>The general idea of browsers "fixing" errors the encounter is the source of
>many of the problems we now have (however it did allow for
>forwards-compatibility in many cases). If something is a clear error then
>it's much better to let the user know that (especially if the "let me guess"
>and "don't ask me about this again" options are clear).

Agreed.

You may find that my post to the TAG list entirely in agreement with
what you are saying, here.

I didn't quite get my remark about the TAG into a PS in the first instance,
but it was clearly an afterthought and widening of the context.

I did do and write up the homework to explain to the confused what was
going on in the present instance.

I could have linked in my TAG post at the first instance.  I should have
made the line between the Finding and what I could recommend clearer.

The 'natural order of things' to which I referred is that a type agreement
assertion based on successful processing is more reliable than a type
agreement asserted in MIME headers.  When theories clash, it helps to check
the facts.

Al

Prior post for ready reference:

  http://lists.w3.org/Archives/Public/w3c-wai-ig/2002OctDec/0603.html

TAG list post comparing type checking and fixing with the management of 
conditional content:

  http://lists.w3.org/Archives/Public/www-tag/2002May/0134.html

Please also read the contributions of Tantek Celik to that debate in the
TAG.  You have to understand the truth of what he is saying to come up with
a practical plan for what to do.  Saying we just need the servers to be
better administered is not a practical plan.  Saying browsers should just
throw an error is not a practical plan, either.

We certainly need to be waging a campaign to arrive at more orthodox coding
on the Web.  But saying that browsers simply shouldn't fix things is too far
out of the bounds of reasonable approaches to be an effective strategy in
that campaign.  Browsers shouldn't "simply fix things" but neither is it
true that they "simply shouldn't fix things."  We need a practice
that is less simple; enough so that it includes both error rejection and
error correction, each in its place.

See

  BCP DTDs would get used
  http://lists.w3.org/Archives/Public/www-qa/2002Nov/0016.html

for an example of what I think might prove effective as a tactic in an
orthodoxy campaign.  And yes, it involves fudging the line on orthodoxy
relative to the current W3C understanding.  [In a controlled way...]

Received on Tuesday, 3 December 2002 10:10:34 UTC