On Sun, 2003-02-02 at 00:01, Jordan Bettis wrote: > I think someone suggested that the author doesn't include any newlines > in the paragraph so the reader's MUA can wrap lines where he > specifies. That would be me. > There are two problems there. First is the previously > mentioned problem with quoting. I've noticed that MUAs that don't > insert newlines at the end of their lines are the same ones that > promote horrible quoting practices (ie, composing the entire previous > message after a -- Original Message -- line). Honestly, at that point > the quoted text has become so useless that it might as well have just > been excluded from the reply to save bandwidth and storage space. That's not an effect of not wrapping lines at the sender's end; that's a completely different (and bad, I agree) behavior of MUAs that _happen_ to not wrap lines. > The other big problem with the no-newlines idea is that the sender > loses the ability to apply special formatting to her message to make > ASCII art or tables (for instance). She has no idea where the reader's > MUA is going to wrap the lines so her neat diagrams and tables could > end up being a bunch of incomprehensible gibberish to the reader. She has no idea anyway, as MUAs do generally wrap lines, and terminal/window widths vary widely. SVG solves this problem nicely for diagrams, and HTML solves this problem nicely for tables. Use these if you are going to do things like that. > The best reason I can think of for wrapping at <=72 characters is that > the standard requires it. The *only* appropriate place for this > discussion would be in an ITEF working group for the purpose of > updating the standard. Until RFC 278 (and all other RFCs that mention > the 72 character limit) are obsoleted by a standard that suggests > something different, or until we quit using plaintext messaging, then > MUAs must wrap the text they send at 72 characters. That's all ye know > on earth and all ye need know. HTML again: you can wrap lines in HTML source all you want, but the rendered output is always displayed fitted to the width of your display. That way, you get around this limit without breaking any standards. Unfortunately, there are a few problems with using HTML for email. First of all, it consumes much more bandwidth than plain text does (although this is slowly becoming irrelevant). Second, many MUAs cannot read it (although at least rudimentary HTML support is in many MUAs these days). I'm sure there are other reasons that make HTML inappropriate for email, at least for the time being. Anyone care to comment? Alex. -- PGP Public Key: http://aoi.dyndns.org/~alex/pgp-public-key -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS d- s:++ a18 C++(++++)>$ UL+++(++++) P--- L+++>++++ E---- W+(+++) N- o-- K+ w--- !O M(+) V-- PS+++ PE-- Y+ PGP+(+++) t* 5-- X-- R tv b- DI D+++ G e h! !r y ------END GEEK CODE BLOCK------
Attachment:
signature.asc
Description: This is a digitally signed message part