CSS Limitations for Email

Replies to This Discussion

Permalink Reply by rayrad on March 28, 2008 at 7:26am

There are other things as well that I am not recalling at the moment, but one thing that I noticed with the Outlook 2007 client (which has a completely new HTML rendering engine and no longer uses Word's) is that styles on parent elements do not necessarily pass on to child elements. For instance, if you have HTML that looks like this:

<div style="font-weight:bold; font-size: 1.2em">
<div>This is some text</div>
</div>

...then the text, "This is some text" will NOT pick up the style attributes from the parent

. You have to apply all styles you want to each level of the hierarchy. I have not experimented with this a great deal, so there may be conditions where this is or is not true, but this is certainly what I experienced creating an email newsletter for a client.

▶ Reply to This

Permalink Reply by Alf Brand on March 28, 2008 at 1:38pm

If you search Google for "CSS in email" you'll find a few good articles on this subject.

The main limitation is that you want to refrain from placing your css in the of your document, or linking to an external .css file. Keep all of your CSS in-line (e.g. < p style="border:1px solid #c00; font-size:12px;">).
Unfortunately CSS selectors like e:hover or e:focus cannot be accessed inline so support for these are limited.

▶ Reply to This

Permalink Reply by Ron Blaisdell on April 27, 2008 at 7:13am

Probably the best single source for this information is the Email Standards Project. They show you exactly what CSS is supported and on which email clients and systems.

Outlook 2007 is especially a problem child, and I have taken to using Premailer with my handcoded campaigns to make sure I have code that will work the best on the majority of platforms. I code them the way I want - Premailer makes all the inline CSS for me.

▶ Reply to This

Permalink Reply by Warren Diggles on December 11, 2008 at 9:12pm

Thank you for the link to ESP, now I know why I couldn't get a background position bottom for gmail

▶ Reply to This

Permalink Reply by Balachandra on July 31, 2008 at 1:28pm

External and Internal CSS are not support all ISP's. Inline CSS is only support all ISP's.

Inline CSS — Ex. style="font-family: Arial; font-size: 10pt; color: #000000"

Div and P tags are not support all ISP's.

▶ Reply to This

Permalink Reply by Al Anderson on December 15, 2008 at 1:25pm

One thing that I like to do is to use the old school tag. I can specify things like family in the "face" attribute and give the general size that I am looking for. Then I add an inline style attribute to it to get more specific for the clients that utilize it.

▶ Reply to This

Permalink Reply by Paul Bee on September 4, 2009 at 1:52pm

To address our subscribers, the most frequently used webmails and email client software that pay attention to, and thus we design for, are Outlook 2003 / Express / 2007, Gmail, Hotmail, Old Yahoo and New Yahoo, Aol 9, Live Mail and Thunderbird. We view the webmail tests in both Internet Explorer 7+ and Firefox.

The only presentational elements that reliably work across every one of those are background color, border, border-collapse (rarely used), color, font-size, font-style, font-variant (rarely), font-weight, letter-spacing, line-height, padding, table-layout (rarely), text-decoration, text-indent and text-transform.

The only way to reliably ensure the faithful presentation of the intended design of the email across the above browsers and mail systems is by doubling up the presence of these selectors with both embedded (in code style="") and inline (head of page + embedded class="").

The decision to stray outside of the reliable elements is reviewed every 6 months by looking at the statistics of email systems being used by our subscribers.

Generally, if the email is not faithful across the test zones, it's because the .html has been handed to us by an external source and someone has forgotten that that email template design is about going back to basics with the .html. So generally semantic code is avoided except for the odd 'div' or occasional 'p', and the doctype is always loose or transitional html. Including DocTypeDeclaration can simply help to spot coding typos through validation if tables are exploded/broken.

Hope this helps.

▶ Reply to This