
On Fri, 2010-04-16 at 08:28 +0100, Thomas Davie wrote:
On 16 Apr 2010, at 08:20, Ertugrul Soeylemez wrote:
Juan Pedro Bolivar Puente
wrote: I am going a bit off-topic here...
Me too, but that's how mailing lists work. =)
And what is the universally best length of line anyway? I have also seen people sending emails with really thin columns that get annoying to read... If you feel bad about emails sent with long lines, just enable text wrapping in your email reader.
The big problem is that some mail/news readers assume that lines are prebroken, especially when it comes to older terminal-based readers.
I'd highly recommend that you stop using such readers, or patch them to soft-wrap long lines, neither is difficult.
Except that it may be a line which should not be wrapped. For example ascii table should not be wrapped as it destroys the content. Pice of code in Haskell or python as well. And pre-breaking have little problems, confirms to RFC and causes no problems (excepts in broken screen readers. I understand that software should be accessible but it should follow the conventions that was already established a long time ago).
In fact I would love if HTML mails would be more accepted in the open source community. After all there is nothing bad about HTML and it would solve the above problem. Most reasonings against it are related to compatibility or interoperability, which is no problem, because you can always add a text/plain part.
Add quoting and size. While for 'normal' users it is not a problem it might be problem for users which uses EDGE/GPRS/... to get their mail. From example from http://www.asciiribbon.org/ (not counting sound as it lazy download) - it's 231 K. Text plain is 3K. If you can download 1 MB via EDGE/GPRS/... or pay a lot for extra download - it HAVE a difference (compare using 23% of limit to download a mail and 0.3%). Personally I'd choose to always show text/plain message as: - Security reasons. Last time I heard about text/plain exploit was here - http://ur1.ca/ve1h ;). Ok - I don't use Outlook Express or anything on MSHTML but still there are exploits from time to time. - I cannot use terminal. Sometimes I have to use terminal to browse web/read e-mail. I can tell that HTML engines on terminal are terribly underdeveloped. - Quoting. text/plain quoting is very simple. HTML quoting can be quite hard - how to quote a part of table? what to do with CSS?
I suspect the only way this would solve the problem is by forcing people not to use broken email clients – you can't read an html email in an old email client, in the same way as you can't read a non-hard-wrapped email in an ancient email client.
If you mean by 'ancient' released not longer then month ago and confirming to spec then yes ;)
Anyway, my basic point is that an email client that will not soft-wrap lines is fundamentally broken. Emails can and do have lines longer than 80 characters, and a client that can't render them has a serious bug. If your client is one of these, I suggest you either (a) move to a less buggy client, or (b) write a patch to fix the bug. The correct solution though is not to enforce upon everyone else that they must write emails with a particular line length.
Bob
Hmm. I guess you can send to the IEFT - all I found in RFC was limits (ok. different - 60, 78 and 80). Regards