Sorry for late reply, postponed then forgot to send...
=- Tony's unattended mail wrote on Tue 20.Nov'12 at 21:02:56 +0000 -=
> 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.
> {...}
> 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.
I guess you put too much interpretation/ meaning in plain-text/
"text/plain": LF is just that, nothing else, 2 LF are a paragraph,
that's it.
If you want to put more semantics into it, you should use something
else than plain-text, like HTML or even more structured formats.
While you expect readers to narrow down too long lines, you deny
unwrapping because you _assume_ there is more meaning to LF than
just that. Hmm... how often does this really apply?
More often than not plain-text is just plain-text and no poem. ;)
Then unwrapping is as easy as wrapping.
And we could keep it "normalized" for when you don't/can't wrap.
> 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.
mailman (and majordomo?) have "duplicate checks".
> > Why is it OK to produce bad stuff and require others to improve
> > it afterwards?
>
> 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).
Heh, how do you know we don't blame it? :)
Afterall we have CSS now, and html5 coming. ;)
--
© Rado S. -- You must provide YOUR effort for your goal!
EVERY effort counts: at least to show your attitude.
You're responsible for ALL you do: you get what you give.
