Zen and the art of CSS in Email

The wise one must run away from the old nightmare of table-based layouts and dozens of email clients into the road less traveled. One must accept the different paths of content and structure to completely understand the beauty of the Cascading Style Sheets.

I wish all could be that simple.

Unfortunately, the use of valid markup (XHTML) and CSS in email is quite a vision in these days. Most of the email clients have a subset of HTML, usually a poor implementation of the W3C guidelines or even some proprietary markup (MSHTML or web based clients).

When most of the developers are having fun with the beauties of XHTML, they suddenly have to go back to the hideous and deprecated <font> tag and coding emails with limited table-based layouts. Then they have to put a lot of faith that all would render correctly in most email clients and ignore they just blew away the semantic structure of the document.

Add to that the fact that most of unsolicited commercial email (a.k.a. Spam) is a plague that firewalls try to block, harming some of the legit marketing actions and you see that it is really a hard days night for a developer.

There is some hope though. Based in my humble experience and some research, I tried to collect a few tips regarding the development of e-letters with the use of CSS.
A essential reading is the ALA article from Mark Wyner, where he tests some solutions for common problems in the development of “semi-compliant” HTML email.

For a start we must assume a few things:

  • It is impossible to please everybody. You just donÂ’t have the resources to test your HTML email in every platform and email client. This does not mean that you should design for the least common denominator (only plain text) but instead try to reach most of you audience, yet providing a rich experience for those clients who subscribed you HTML newsletter;
  • Some hacks and invalid markup might be necessary. ItÂ’s just the way it is, as some clients keep messing up your formerly correct markup.
  • Avoid using proprietary technologies (font embedding, Active-X controls, Flash, Javascript);
  • Be ready for a few surprises with web based email clients, since they usually bite, chew and spit your HTML before feeding it to the users;
  • ItÂ’s important to upgrade to CSS layouts in email is that people are starting to read email in mobile devices, where table-layouts are mostly useless and cause an increase in file size;

And now, the tips and tricks to CSS in email:

  • Style Overruling.This might go both ways. You might loose your formatting because of the global rules of the original client or you might affect the email client interface, especially when applying global selectors (A, P, IMG). To avoid this behavior I advise you to style each tag with a particular classname element .classname{}or provide inline stylesheets (style=" ... ") since these take the highest precedence.
  • Tag stripping.
    A common procedure in email clients, especially in web based ones, is the trimming and/or replacement of tags, leaving only the body of the message, making useless any HEAD declaration.
    The usual countermeasure is to enclose our content within a DIV and apply a style to that block container as if it was the BODY container.
  • Quirks can help you.
    Sometimes, the poor implementation can help you render an alternative version of the email. For example, you could provide a initial block (before other body content) with {display:none} so the clients that read only plain text could see the text only version.
  • Hotmail mode.
    There area 2 alternatives to make your styles work in Hotmail. One solution is to declare the style block within BODY since the engine usually removes it. The other one involves the hard work of setting inline styles in each and every element that needs to be formatted. Usually the first way is much better (although invalid markup) since it involves a lot less work.
  • In the end, you might get a graceful rendering of you newsletter. If CSS was supported correctly the advantages would be fabulous, since we could get structure, metadata and semantic relations with the email. This could provide us with alternate presentation modes (how about a property @media=email ?), easier indexing and filtering, enhanced linking and support for additional encoding. Not to mention that it would look real nice.

    The road less traveled stands before us, and as we embraced the challenged of web pages with correct markup, we now must overcame the same challenges in email.

    As in the zen story of the Ten Bulls, we start with the “The Search for the Bull” and eventually end “Reaching the Source” and “Into the World”, accepting and understanding the way things work with CSS and email.

    I just hope that this path might be a little less complicated than taming the bull.


One thought on “Zen and the art of CSS in Email

Comments are closed.