19 Responses to “The campaign to end HTML email”

1. Nicholas says:
   January 20th, 2007 at 12:12 am

   I’m not sure I really agree: I’ve commented on this post at

   http://www.renhip.com/blog/2007/01/19/html-email/

2. Tim Gaden says:
   January 20th, 2007 at 12:21 am

   Thanks for the link.

   I’m not so sure about the proportional font argument you advance. I’m happily viewing my plain text emails in Lucida Grande.

3. Scott Hughes says:
   January 20th, 2007 at 12:25 am

   I mostly agree, it’s not necessarily a bad thing and can be useful. More to the point it would be better if all mail apps handled it correctly and safely.

   Especially replying and forwarding.

   I have a worse situation at work as we are mandated to use the MS Rich Text Format in MS Outlook.

4. Nicholas says:
   January 20th, 2007 at 12:29 am

   Well. My only point is that many people get to read ugly text messages, that stand out from the rest. Of course, Mail.app is better behaived, and even Outlook can be made to Do the Right Thing(TM) but it doesn’t by default. And, indeed, there is an argument either way.

5. Uno says:
   January 20th, 2007 at 12:39 am

   There’s no real difference between the ability to view HTML mail and the ability to view HTML in a browser. One could argue that no computer running Windows should ever be allowed to go online, but that’s a different discussion.

   I say what Marie Antoinette didn’t: Let them eat cake.

   People that want to read email in Courier New or Monaco can always find a way of doing so without ruining it for the rest.

6. jason says:
   January 20th, 2007 at 12:54 am

   HTML email isn’t the problem, it’s the fact that spammers use HTML email in nefarious ways. if we had adequate ways of blocking unsolicited email, then we could be using flash in emails.

   can you tell i do email marketing? haha

7. Gibbons Burke says:
   January 20th, 2007 at 1:26 am

   I used to be a plain text purist, and used the hint mentioned above to force all incoming mail messages to be displayed that way, but then I found I was losing a lot of the context of the emails I was receiving. If someone had bolded a relevant passage, or used italics that would be lost in translation to plain text. Also formatting of inline images got munged. So I go with the flow, and have learned the keyboard commands to quickly turn something I”m looking at into plain text if I want to see it that way.

   My biggest problem with going with this particular flow is that some correspondents have their HTML text size set so small I can hardly read it. That service seems to render mail in a default font that is unreadable, and Mail.app’s Webkit html renderer doesn’t heed the line in the Mail plist (~/Library/Preferences/com.apple.mail.plist) named ‘WebKitMinimumFontSize’ which lets you *set* this limit. I wish it would respect this setting, and also wish there was an easy way to set it in the Mail Preferences. This would save me a lot of squinting and unnecessary keyboard work.

   For these mails Command-[ will render the offending email in plain text (I use Monaco 11, which is nice) so it is readable.

   Also, some html mail doesn’t flow properly to the margins of my viewing area, which, given I’m using the Letterbox three pane view, is limited. Rendering those in plain text helps too, but it is annoying to deal with.

   I compose mainly in plain text, but often do rich text in order to include images inline with the text which explains the images. This can’t be done with plain text - and Outlook users simply see the first block of text in their viewer. From the first image on every block of text in the message is included as a separate attachment, and I find my recipients don’t know to open them to see what I’ve written.

8. Tim Gaden says:
   January 20th, 2007 at 1:50 am

   Gibbons, I think you need to create a new key: MinimumHTMLFontSize

   See further, “Setting a minimum HTML font size“.

   This works flawlessly for me.

9. Jesse David Hollington says:
   January 20th, 2007 at 1:51 am

   There’s little damage that a bold, italic, or colour tag is going to be able to do to your computer.

   The problem isn’t HTML e-mail, and let’s not throw out the baby with the bathwater. There are many things that can be done to prevent HTML e-mail from being problematic, and frankly no programmer in their right mind should have ever allowed an e-mail client to run embedded Javascript or VBscript, as early versions of Outlook did. It’s this silliness that has given HTML e-mail a bad reputation.

   Even allowing for off-site links for image display is going too far, in my opinion. I think if people actually embedded the images, the whole experience would be more sensible from a security point of view (e-mails would be larger, of course, but there would be less of a security issue — right now linking to the images back at a hosting web site really just shifts the problem anyway…. Network traffic is created when opening the e-mail, as opposed to when receiving it, but other than disk storage issues, the differences are minimal).

   I normally send text e-mail (as Mail.app does by default in my case), and will only switch to rich-text when I want to add formatting (in which case Mail.app reminds me that it’s about to do this, and nicely gives me a choice, which is good as I do have some people I communicate with who can’t receive HTML e-mail properly, or prefer not to due to their choice of e-mail client and/or mobile device).

10. David Cramer says:
    January 20th, 2007 at 3:05 am

    I far prefer plain text email, and use Eudora 6.2.4 in Mac OS X (10.4.8). I prefer non-proportional text (Lucida Grande).

    Eudora is way too fast and too useful for me to abandon, although it has its limitations. However, the only one that affects me is its lack of effective support for HTML email. For those messages I have set up a Keyboard Maestro keyboard shortcut to view the message in Safari.

11. S. Kennedy says:
    January 20th, 2007 at 3:26 am

    I have been using Gyazmail for a couple of years now and one of the things I like about it is the way it handles HTML. All of my incoming emails are displayed in plain text by default but if needed I have a keyboard shortcut to toggle between plain text and HTML (option h). I can also double click on the HTML icon and open the message in a browser. Normally I find the plain text version much easier to read than the formatted text version. some of the reasons having been discussed already. Gayzmail has a very large list of keyboard shortcuts that can be programmed to about any key sequence you want.

12. Michael says:
    January 20th, 2007 at 4:33 am

    “There’s no real difference between the ability to view HTML mail and the ability to view HTML in a browser.”

    This is an interesting point. I’d be inclined to add that there’s little difference between running JavaScript in an HTML mail and running it in a browser. And further to that, I’m inclined to say that running scripts willy-nilly in a browser is no longer sensible. It’s been estimated recently that some 100 million websites have cross-site scripting vulnerabilities. On Windows I now use this with Firefox:

    http://www.noscript.net/whats

    As for HTML, I think there is, as Uno says, no absolute difference. But I think there *is* something like a judgment call there.

    One would want to bear in mind that email is an informal medium and doesn’t generally call for much formatting. This is one reason why we might have done better to stick with the original standard for formatted email (see rfc1896) that was designed specifically for the job, that is parsed easily, and that degrades well.

    In fact, *Hypertext* mark up language (HTML) is really aimed at creating a public space enabling hypertext - non-sequential reading of documents or parts of documents by jumping within or between them. You can jump out of email via a link; you can’t jump into it; and it’s not (in general) a public medium. It serves a different role from the web.

    Furthermore, there are certainly far more email clients than browsers in use - and the HTML support (and HTML authoring) of much email software is limited to say the least and deeply flawed by non-standard implementations. The position is further complicated by webmail, which is effectively viewed in a webpage. This means for example that the body tags from HTML emails (few and far between) have to be stripped out, so that there are not two sets of them in the rendered page. This can mess up the desired formatting. Here’s an enlightening link that goes into HTML email authoring and its problems in some depth:

    http://www.anandgraves.com/html-email-guide

    While some formatting can sometimes be useful, it’s on the whole less useful than it is on the web. Viewing HTML in one application may not be inherently different from viewing it in another, but HTML is less applicable to some purposes than others and practically speaking can cause rendering problems for some recipients. Consequently, it can’t be wrong for someone to make the judgment that he’d better not use HTML for email in at least some situations.

13. Chip.Cuccio.US says:
    January 20th, 2007 at 5:03 am

    Hawk Wings: The campaign to end HTML email…

    Washington Post blogger Brian Krebs uses the recent release of a Windows security patch to fire up the campaign to end HTML email.
    He reminds his readers that “viewing your e-mail in anything other than plain text mode is asking for trouble on a…

14. Gibbons Burke says:
    January 20th, 2007 at 5:19 am

    Thanks for the great tip on adding the ‘MinimumHTMLFontSize’ - that works like a charm - except now I can’t use Monaco 11 anymore - it bumps it up to Monaco 12! Ah, well, se la guerre.

    I still think Apple should expose this feature in the Fonts & Colors preferences pane for the application!

    I find that AOHell is one of the worst-formatted mail sources for Mail.app. It’s HTML formatted messages contained the following tags (with the tag symbols removed so they will display properly):

    FONT FACE=3Darial,helvetica
    HTML
    FONT SIZE=3D2 PTSIZE=3D10 FAMILY==3D”SANSSERIF” FACE=3D”Arial” LANG=3D”0″

    Messages from AOHell clients are rendered in Mail.app as unreadably (for my 44 year old eyes anyway) small text. I don’t have any hope that AOHell will make things better, but Mail.app could do a better job making life easier for its hard-of-seeing users by allowing explicit and official control over the minimum font size.

    By the way, while composing this reply I found a way to make Safari freeze with a spinning beach-ball coma using this Reply form. Turn “Enable live preview” on and type two less than signs into the reply field. Freezes my Safari up every time. I will probably report this on the Webkit bugzilla, but there may be some culpability in the preview javascript.

    Gibbons

15. Steve L says:
    January 20th, 2007 at 8:25 am

    Thanks for this Tim (and others)-great stuff!

    As intimated earlier, I recently struck problems with html emails (’font mis-translation’) to/from friends using different clients (Outlook 2007, The Bat!, Entourage, Thunderturd etc).

    I have also struggled with the ‘impossibly small fonts’ problem: so, thanks for that tip too.

    In my work environment, I use Lotus Notes (no choice), and regularly send html emails to a distribution list of several hundred people. I also send a copy to myself, which I read in various email clients to see what my newsletters are like at the other end.

    In one email, I had a bulleted list: at the ‘the other end’, in various clients (including GMail web-interface), the list was a dog’s breakfast!

    Recoiling in horror, I went back to plain text for a while, but now have reverted to very simple html emails (no tables, no bulleted lists etc).

    As a non-expert user, I think ‘the baby and bath water’ approach to the question of html email is the most reasonable: the tricky bit is discerning which is which.

    Steve L

16. Tim Gaden says:
    January 20th, 2007 at 11:52 pm

    Mail.app users should be a little reserved in criticising the way other clients code up HTML.

    Have a look at the way Mail.app’s “rich text” is done.

17. Steve L says:
    January 21st, 2007 at 8:05 am

    ‘Mail.app users should be a little reserved in criticising the way other clients code up HTML.’

    ‘Agreed Tim, and I think I mentioned in a comment on an earlier blog that Apple Mail on my machine was doing strange things -or at least partly involved? - with fonts in mails sent to/from friends using other email clients. eg emails I had written in say 12 point were seen at the other end 3-4 points smaller, and, on the receiving, fonts in mails written to be say 11 pt were seen by ‘me’ (Mail) as 3-4 fonts bigger. (BTW, Entourage was doing strange things with font size also)

    SL

18. Michael says:
    January 22nd, 2007 at 1:12 am

    “Mail.app users should be a little reserved in criticising the way other clients code up HTML.”

    I wouldn’t agree with that, because the implication there is that the users are responsible for the state of the HTML composer, but they’re not because they didn’t write the software. Furthermore, I don’t think anyone should be at all reserved in pointing out genuine flaws in software. Apart from anything else, if that’s done it can serve as a warning to people using the software. How would they know, otherwise?

    So far as Mail’s HTML composer goes, I don’t think it’s too bad. I think one gets better results writing a page by hand, saving it as an HTML file, opening it in Safari, and pressing Command + I to send the markup direct to Mail.app. But then you need to know markup to do that, and most users don’t. And as far as WYSIWYG HTML composers in email clients go Mail’s isn’t too bad. Compare what Outlook does when using Word as the email editor - or look at this horrific example of Incredimail authoring:

    http://www.radsoft.net/resources/rants/20020627,00.shtml

    But whatever client you’re using you of course get maximum interoperability with plain text. it should at least be there as part of a multipart/alternative message.

19. On a blog without a name › HTML Email says:
    February 21st, 2008 at 7:35 pm

    [...] is something luddite-ish about the current attitude to HTML email, even from those who take a measured approach. Some people are dead against it, recommending that you configure your clients to avoid it, and [...]

Leave a Reply