Style In Email

From CSS Discuss

Jump to: navigation, search

Contents

HTML Email and Using Style

General Notes

An Email template is usually sent as a single-part or a multi-part. There are several MIME types associated with the various parts, the most common being text/plain, text/enriched and text/html. The only MIME type on topic for this WIKI is the HTML. This document addresses CSS that works safely in the majority of cases. If you have questions about overall email template layouts and syntax, you can contact Elizabeth Davies directly.


HTML in Email

Email readers have far greater diversity than browsers and support of HTML ranges from none to limited CSS. While a few of the newest mail readers might support CSS, its almost always safest to stay with very conservative (old) markup. HTML for emails going to the overall web should be written in HTML3.2 with limited use of CSS1.
Design your HTML with the following guidelines:
  • Use HTML3.2 DOCTYPE for all email going to non-restricted internet domains
  • If your audience is restricted to AOL, you can safely use HTML4.01 transitional or experiment with XHTML1.0
  • Validate the HTML and keep it very clean. After you validate, shred the validation with the following hacks.
  • Use CSS1 and extremely limited CSS2. If NN4.7 can parse it, it's probably safe. Otherwise: TEST.
Keep in mind:
  • Positioning is poorly or wildly supported: it's best not to use it at all.
  • Linked and Imported style sheets are not supported in the large majority of mailreaders. They work in some versions of Outlook, but this functionality is usually disabled.
  • Most webmail browsers truncate/chop off the header. This translates to no style if you rely on an embedded style definition list. Use of embedded styles vary depending on the intended audience, even if you use it back it up in the body.


    • Define the embedded style in the header with specificity:
font.myclass { font: bold .8em Verdana; } works in most
.normal { font: bold .8em Verdana; } does NOT work in many
    • Although seemingly counter-intuitive and very verbose, the most consistent browsing experience for text can be reached using the following logic:
some text goes here but I am going to
<a href=" ">
link some text here
</a>
      • Rather than use a

        tag, use a tag with
        tags to create the paragraphs. The tag receives an inline treatment and is understood by the most basic mailreaders that parse HTML. If the email is going out as more of a RTF document (no images or tables) this method will allow all RTF readers to gracefully display the email. Those that are HTML enabled will go further and pick up the defined style.

      • Redefine the font tag inside and after each anchor tag. Some mailreaders have broken inheritance and revert back to their default definitions after each anchor. (see specific mailreader support list below)
      • Redefine again inside the font tag or with an internal using inline style if you're intended audience uses webmail.


How this works? A mailreader with good CSS support will read the embedded style and apply it. It will then apply the inline style. You can get away with more on the embedded side than inline, so plan for graceful degradation. A mailreader that strips the header but sees inline style will ignore the font attributes and the class and honor the inline definitions. A mailreader that doesn't see any CSS will honor the font tag attributes.
The above example redefines styles for a font, but typically you would have items in the embedded style that do not work well using inline definitions. Any styling of the body tag should be in the embedded style as well as inline. The <body> tag is unevenly treated for style.

Mailreader/Browser Specifics

Note: The most up to date support information for email applications is at Campaign Monitor's Guide to CSS in Email.

  • AOL5
    • No HTML
    • parses email as Rich Text (RTF)
    • word wraps
    • hyperlinks are honored
    • does not honor inheritance of font attributes.
    • AOL5 for Mac only sees attribute colors defined in hexidecimal. Most remaining AOL customers using AOL5 are Mac users.
  • AOL6 and AOL7
    • HTML unless overidden by user
    • if overidden by user, displays enriched/text
    • parses embedded style, relative positioning now works consistently
    • image maps now work consistently (as of release of AOL9)
    • background images are not supported, relying on a repeating background will shatter the design
    • requires specific definitions in the embedded style (p.myclass, span.myclass)
    • mailreader window is 470 pixels wide
    • browser and mailreader use the Netscape Gecko engine
    • no scripting including javascript
    • mailreader supports IFRAMES and linked style (sample page: http://www224.pair.com/gryphon/cyberlaw when sent as a full HTML email displays properly with the exception of the javascript)
  • AOL8
    • HTML with images displayed by default
    • if overidden by user, displays enriched/text
    • user can set their default view to not allow images, but show the HTML
    • handles style same as 6 and 7, allows for larger default window display
    • image maps now work consistently (as of release of AOL9)
    • some background images are supported, but strict testing of location and use necessary
    • mailreader window is 530 pixels wide (broadband can be up to 570 pixels wide)
    • browser and mailreader use the Netscape Gecko engine
    • no scripting including javascript
    • mailreader supports IFRAMES and linked style (sample page: http://www224.pair.com/gryphon/cyberlaw when sent as a full HTML email displays properly with the exception of the javascript)
  • AOL9
    • Supports a great deal of CSS. AOL9 forces the installation of IE6 for a browser and the mail reader appears to be capable of most of what IE6 is (along with all the bugs). Positioning IS supported, but unless you know that your users all have version 9, do not use any absolute positioning. This behaves very differently in lower versions since it sets the 0,0 position at the top of the mail window rather than the top of the html body. In lower versions, that position has all of the email header information listed. Relative positioning will work in all versions above AOL5.
    • mailreader window is 570 pixels wide.
    • default settings have images turned OFF for email. The user must actively accept each email images and does not have the option of setting global images on (as they did with previous versions).
    • no scripting including javascript
    • image maps work consistently
    • mailreader supports IFRAMES and linked style (sample page: http://www224.pair.com/gryphon/cyberlaw when sent as a full HTML email displays properly with the exception of the javascript)
  • AOL Webmail ( this web mailreader stays fairly current with the newest AOL browser and its behavior is expected to shift about 6 months after the release of each major AOL version to match the newer mailreader behavior )
    • defaults to HTML email
    • truncates all headers
    • honors inline style
    • no positioning
    • mailreader window is 530 pixels wide
  • Hotmail/Yahoo/MSN Webmail
    • allows HTML according to user preferences
    • if HTML is not allowed, defaults to text/plain MIME type
    • truncates all headers
    • honors inline style
    • no positioning
    • removes CSS margin settings
  • Opera M2
    • HTML mail is rendered using Opera's presto rendering engine, except resources linked to external URLS are suppressed by default and No scripting is supported at all. Inline style supported. User has option to show text or HTML parts of multipart messages.
    • No capability to compose HTML email.
  • Outlook98
    • HTML -- user must set preference, normally overidden to text in corporate settings
    • can default to either text/enriched OR text/plain depending on settings
  • Outlook 2K/XP/2003
    • HTML -- user must set preference, normally overidden to text in corporate settings
    • mailreader defaults to the IE version installed on the user's system
    • can default to either text/enriched OR text/plain depending on settings
    • will display inline, embedded, linked styles, iframes, positioning. CSS support is the same as the parent browser with all of the same bugs.
    • mailreader supports IFRAMES if the browser does (sample page: http://www224.pair.com/gryphon/cyberlaw when sent as a full HTML email displays properly on a Win2K system running IE5.5 and Outlook2K -- with the exception of the javascript tabs not shifting style color)
  • Squirrel Mail
    • text/plain MIME type is the default, allows user to set to HTML
    • no linked style sheets
    • no positioning
  • Mozilla Mail/Thunderbird
    • HTML
    • user can choose from text/plain, simple HMTL, or original HTML on a per-message basis
    • honors inline style
    • should have all the display capabilities of the Gecko rendering engine embedded in the application
    • do not use absolute positioning (see Mozilla bug 121878)
  • Mail.app 1.3(v606) [included in Apple Mac OS 10.3]
    • HTML version
    • should have all the display capabilities of the Safari ( Web Kit ) rendering engine embedded in the application

Other Resources

Personal tools