Re: format=flowed : why not use HTML?1998-08-20 18:35:20
At 2:49 PM -0400 8/19/98, Keith Moore wrote:
>> Text/enriched is >> probably more widely deployed in mail programs than text/html, it has a >> much simpler syntax (only "<<" for quoting the "<" symbol and "<nofill>" >> for doing forced-wrap text), and still people wouldn't accept it, let alone >> generate it reasonably. I think using any kind of internal markup that is >> not fully text/plain compatible is a losing battle. > >Okay, so this really is the quoted-printable problem all over again. >People won't generate that reasonably either...though I've always >wondered if this is because it seems too difficult, or they haven't >tried, or they didn't think of it, or they just don't care. It has always seemed to me the real difficulty was senders lack confidence that receivers will be able to render the message as the sender intended. I don't believe this results from the inadequacy of the protocols we've devised. Rather it comes from users' unfamiliarity, and from their perception the protocols aren't always "there". Even though this community has been working on MIME-related issues for well-nigh a decade, for the overwhelming majority this is still new. Heck, just e-mail is new for many. Couple this with our struggle to find idioms that make e-mail markup intuitively easy to employ and to render, and you have the situation that most people use these tools tentatively with the expectation something will go wrong. I have trouble understanding "not fully text/plain compatible". text/html and text/enriched code their directives in plain text. I'm not sure how much more compatible we can make them. The directives are messages at a different level than the message between sender and receiver. Encoding them in the whole package used to convey the message is our only vehicle. Negotiation between the sender and receiver over message encoding is not possible in a store-and-forward environment. We could have adopted a different strategy than including directives in-line, but those methods are not without their problems. text/html and text/enriched are reasonable, pragmatic choices. The underlying problem in discussions like this one is when the different levels are exposed, users' assumptions about their environment are violated. Those events weaken users' trust in the protocols. Because this occurs too frequently in typical correspondence, we still lack faith in our protocols' design. When the environment becomes the same for all users - employment of text/html and/or text/enriched is consistent and routine, then we'll no longer have this discussion. As a society, we don't really question the universal availability or suitability of pen and paper. Yet there was a time where its applicability to convey a message was doubted. So it will be for text/html. john noerenberg jwn2(_at_)qualcomm(_dot_)com ---------------------------------------------------------------------- --if we are to be saved, it will not be by Romans but by saints. -- Thomas Cahill, "how the Irish Saved Civilization", 1995 ----------------------------------------------------------------------
|
|