HTML email is useful for advertising, but has no benefit for the vast majority of the use of email.
Plain text email (the standard that even most programs that compose HTML mail send out) has traditionally been based around monospaced fonts to permit indenting and ASCII art diagrams. It has also traditionally had line lengths a bit less than 80 columns, initially because in the early days 80 column displays were a standard and in modern times because people still have email display configurations based around a lot of ~76 column email and the noteworthy corner case of Braille displays which are 80 column. For things which can't cope with >80 columns nowadays the common case seems to be phones which mostly can't properly cope with even 80 columns - the portrait layout for the terminal window on my current phone is 52 columns. So we can ignore phones when considering whether to use more than 80 columns. How to make email work on phones is a separate issue. HTML mail often works best for phones. Most programming is done on monitors significantly larger than 80 columns and expressive function names are a good thing to make things easier to understand. So line lengths in programming often exceed 80 columns through constructs like if(func1(func3(param1)) || func2(func4(parm1)) ) for which each of the 4 functions could have names >20 chars and the param could have a name of similar length giving a line length of 130+ characters for a rather simple logical operation. Even outside from direct code there are situations where longer lines are needed. The below is a comment I've just put in some SE Linux policy showing the call graph for user domains which is clearer without wrapping words at <80 columns. A line length of 120 columns would be significantly better for reading code, as a lot of stuff is in the 80-120 range. But it would really suck for Braille having half-length lines and also not be great for quoted text, it would be like the common experience of plain-text 80 column email on a 52 column phone display. A line length of 160 characters would display the vast majority of source code without wrapping and on a Braille display it would cleanly wrap into 2 lines provided that the MUA doesn't try to split on a word boundary. A line length of 152 characters would allow a MUA that splits a line on a work boundary to cleanly fit into 2 lines in the vast majority of cases while not having the second slightly shorter line look too ugly. A text file attachment is one way around the problem but most MUAs don't allow viewing it inline. A phone MUA will often launch a separate program and even if it's a separate window of the same program that is unpleasant to read for a phone display and often annoying for a desktop PC configuration. What do you think? # userdom_login_user_template() -> userdom_base_user_template() # userdom_restricted_user_template() -> userdom_login_user_template() # userdom_restricted_xwindows_user_template() -> userdom_restricted_user_template() # userdom_restricted_xwindows_user_template(xguest) # userdom_unpriv_user_template() -> userdom_restricted_user_template() # userdom_unpriv_user_template(user/staff/secadm/auditadm) # userdom_admin_user_template() -> userdom_login_user_template() # userdom_admin_user_template(sysadm) # userdom_common_user_template() -> userdom_basic_networking_template() # userdom_unpriv_user_template() -> userdom_common_user_template() # userdom_admin_user_template() -> userdom_common_user_template() -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/ _______________________________________________ luv-main mailing list -- [email protected] To unsubscribe send an email to [email protected]
