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.

‘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

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

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

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

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…

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.

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.