On 2012-11-20, Rado Q <l%...@gmx.de> wrote: > The same argumentation applies to producing "readable" mail: > why fix something on the reader-end when it could/should be fixed at > the source?
To say that you can only have a convention that's mindful of the source XOR the target is to create a false dichotomy. Sometimes it's sensible for the source to make assumptions about the reader, and sometimes it is not, depending on the technical aspects. E.g. if you use a linefeed to end the line of a peom, and then you also use an identical linefeed to guess at where to break a stream of text in a paragraph, it's unreasonable to expect the rendering software to tell the difference, and know how to display this on a phone that's less than 70 characters wide in a font size that the user can read. OTOH, in the case of outlook users doing a reply-all, there is nothing a filtering tool can do to make it right because order is not guaranteed. It would impose an unreasonable amount of sophistication for the filtering tool to hold on to every message and check it against the proper list distribution (and even if this were practical, it would slow down your mail). So in this case, it makes sense for responders to have a list-reply feature and/or honor the mail-followup-to header. > Why is it OK to produce bad stuff and require others to improve it > afterwards? The raw form is better for making the important linefeeds meaningful when there are a diverse number of display devices that cannot rely on a composer to know what they will read it on and format it for them. HTML looks awful, but we don't object because our browsers render it okay most of the time (and when they don't, we don't blame the html, we blame our tool for getting it wrong, or we blame the author for not writing something renders well on lynx, but we don't blame the language in any case).
