[Top] [All Lists]

Re: text/*

1998-11-02 16:09:12
At 1998-11-02 08:54, Laurence Lundblade wrote:

To me the top level types are very rough groupings based on some common 
default treatment we want applied to them. For example multipart/xxx 
defaults to multipart/mixed, a rule that's widely implemented correctly. 
Text/xxx was supposed to default to text/plain, but since the registration 
of text/html (very unreadable to humans) most MUAs have stopped display 
text/xxxx by default.

I disagree with you about the readability of text/html: I'd far rather 
see a message in raw HTML than not see it all. I think that's the idea 
behind text/*.

Now with the rise of HTTP browsers that can read HTML, but mail UAs that 
cannot, the question 'can you interpret HTML' no longer has a trivial 
answer, and saving HTML to a file (where it can be read by a browser) 
becomes a reasonable action for a mail UA.

But I doubt it would make much difference. Much as we all might 
disapprove, I'm sure Netscape et al. would still allow users to generate 
HTML in mail messages no matter what its top-level type is.

I guess for text/* the rules these days amount to this:

1) Does it look OK when splatted directly to the screen of a VT100

2) Are you willing to let it occasionally be treated like an attachment by 
mal-conforming MUAs.


3) If you don't like 2 and want to use a parameter, can you convince the 
standards folks that your type is OK to be identified just by a parameter 
to text/plain.

If you're willing to be liberal about 'OK' in 1, I'd agree with you. For 
instance. I think the registrations of SGML and XML in both text and 
application was appropriate, since some SGML/XML is sufficiently 
'text-like' to be worth showing plain when there's no alternative, and 
some is not.

Ashley Yakeley, Seattle WA

<Prev in Thread] Current Thread [Next in Thread>