Tag: email

Posted on

Email Luddism

Here’s a little rant I’ve been meaning to get out for a while.

Whenever the subject of email client support of some particular email feature comes up, someone always posts a comment to the tune of “HTML doesn’t belong in email anyway, all email should be plain text”. What they’re saying is that they outright reject two important features: MIME and progressive enhancement. Given that MIME is what makes attachments (or any arbitrary binary data, attached or not) possible, I guess they can live without them too. It’s the same technology that allows web servers to identify content types, so while we’re painting with his particularly tarry brush, I guess we should remove CSS, javascript and images from HTML pages as well. That should keep them happy. With all those removed, we can all retreat to the comfort of the command line where our needs will be served admirably by the likes of the wonderful (no joke) elinks.

The whole point of the multipart/alternative data type is progressive enhancement. A client is free to select from the alternatives presented and render as best it can, with an option for manual selection (that is, as long as you don’t use Outlook which doesn’t believe in such things). This applies to the common text/plain > text/html combo as much as it would to text/plain > image/jpeg, or perhaps application/pdf > application/vnd.sun.xml.writer. Now if they restricted their comments to text/html only, I might have some sympathy, as that’s just shoddy behaviour on the part of the sender. However, they usually prefer to throw out the baby with the bath water.

To conclude: MIME is a wonderful thing; some people use it badly; get over it.

Posted on

The Email Standards Project

The Email Standards Project is a worthy effort to try to get email clients to handle HTML email in a consistent way. Many already do pretty well, but there are some big exceptions: Outlook 2007 (with its ancient Word rendering engine), GMail, .Mac, Hotmail and others. Many are opposed to the whole idea of HTML email, but often their resentment is based on the fact that historically email client support has been so bad that they’ve had very poor experiences. Worse is that some senders (not us!) send HTML-only messages, which is certainly something that will drive a Mutt user potty. Smartmessages supports sending in plain, html and mixed formats (settable by each individual subscriber), and we ensure that our users get a clean, reliable platform for delivering their creations, so we try to work around the deficiencies of things like MS Exchange.

Generally the poor support in big-name clients has led to a need to develop HTML for email for very much the lowest common denominator, which for the most part means no CSS (unless you’re prepared to tiptoe through the minefields of using it), no images, no scripts, no forms, no attachments. Too many designers think of email as being just like the web, but it’s not – the vast majority of web pages will simply not work as email. These days the only effective way of designing for email is to start out with classic HTML 4.0 with no CSS or images and make your message look good using only type, white space and colour, because this is probably all that 90% (yes, really that much) of your recipients are going to see. You can then sprinkle a few images in for enhancement, but you should have no text in images that is not shown as text. With the advent of Outlook 2007’s big step backwards, it’s no longer possible to use background images, so you can’t have text over images at all. You also can’t rely on alt attributes as image fallbacks, as some big clients don’t display the alt text if images are being suppressed as an anti-spam measure.

Many designers get very uppity about this kind of thing as it means that their palette of options is severely constrained, however, it should really be regarded as a challenge. It’s not too hard to make stuff look good with heavy use of images (see CSS Zen Garden for gorgeous examples), but producing stuff that looks good with no images or CSS (or more to the point to still look good when those parts have been ripped out) takes a great deal of skill, experience and appreciation of the medium.

Any effort to try and raise the bar gets our support, so props to the Email Standards Project and to Freshview for starting it.