Re: Can we revise RFC3023?

On Thu, 2003-09-18 at 05:01, Graham Klyne wrote:
[...]
> [and a different strand of this thread...]
> 
> On whether text/xml is appropriate for most XML:  I've often heard Ned 
> Freed, an authority on MIME with extensive experience of its use in email, 
> comment that he feels the choice of text/* for HTML was a mistake, because 
> much HTML is not usefully legible to a casual user (techies need not apply 
> for this role).  The intent, as I understand it, of the top-level media 
> type in MIME was not to split formats down by the technology they employ, 
> but rather to distinguish by the expected primary means of 
> presentation.

Yes, pretty much the whole reason for the text/* top level type
was to signal that if you don't grok text/foo, you can display
it as text/plain.

But if he thinks HTML doesn't fit that category, I wonder
if he feels text/enriched does.

I think there's a tolerable level of support for treating
HTML as text/* in browsers; view source has been there
from the beginning, at least. I think text/css gets
treated like application/octet-stream (i.e. you
get a "what's that? i can save the bytes to disk
if you like, but I'm not gonna display it" dialog),
but there was a time when I was hopeful about fixing
that.

Then, the Java deployment wave hit. Most HTTP servers
had file-extension-to-mime-type mappings that defaulted
to text/plain, so foo.java got served as text/plain.
The browser developers, responding to "eek! what's this
garbage on my screen?!?!" from users, responded by
teaching browsers to sniff the content and treating anything
that looked like java as java rather than text/plain.

It's no longer clear to me that this is cost-effective
to fix. The web user community is large enough today
that asking browser developers to fix their handling
of text/* fallback would be like asking auto manufacturers
to change the oil light into something that points
the driver to the right page of a Chilton's manual*.
Technically, it's a correct response, but practically,
the user doesn't know enough to benefit from it.
For a developer, it's great when exceptions launch
the debugger and show you the source. But for most
users... the browser developers' time would be better spent
helping the user figure out where to report
the problem: make it easy for ISPs to make their
support telephone number show up in the browser's
various "something looks wrong" dialogs and such.

The number of complaints W3C gets about spam
just because it's written in HTML with a
<!DOCTYPE...> pointing to us... well, it
doesn't make me feel like more end users should
get to see the textual codes underneath the hood.


-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/

Received on Thursday, 18 September 2003 10:29:00 UTC