Email Standards Project Acid Test

About the Acid Test

Our acid test was inspired by the one created by WaSP. While their acid test is quite extensive and thoroughly tests web standards in great detail, our version tests a limited number of CSS properties constructed with proper markup. But there is a good reason for this.

A blog post on the Campaign Monitor website announced our intention to create the Email Standards Project. But we didn’t dictate how things would evolve. Rather we asked for input from the entire web design/development community. We wanted to know what would be logical and reasonable to ask of email-client developers, and also what kind of baseline support would enable us to design/build solid emails using standards-compliant markup.

The consensus was that we were on the right track. And with some valuable feedback we were able to construct a simple acid test which we used to assess the level of support for web standards in the most popular email clients. (See the results of our tests.)

Send Yourself the Acid Test

Send a copy of the acid test to yourself and test your own email client. Simply enter your email address below and we’ll send you a copy of the test immediately.

Your Email Address

How We Arrived At Our Recommendations List

We understand the challenges of building an email client that supports web standards, especially for webmail clients who must render an HTML document (the email message) inside of another HTML document (their application GUI). And the email environment must contest with spam, which is something websites see little of (except in blog commenting). This brings a whole new element to the equation of HTML support.

With that, we felt we could compromise our list to include only the most fundamental standards support. This will allot email-client developers a buffer without our implying that we have immediate demands, and will also enable us to design/develop compelling HTML emails using standards-based markup. As time progresses we will expand our list of recommendations in hopes that email clients will eventually reach a level of support we see from the web browser market today. After all, web standards in browsers didn’t happen overnight.

What We Tested

Following is a list of what we would like to see every email client support:

This list comprises components we feel are critical to the construct of any standards-based HTML email. To validate the inclusion of each item, we have outlined why we believe each is critical to the overall structure of a standards-based email:

High Priority

Background-image
One core method of delivering accessible content is to call graphical elements using CSS rather than calling them inline. Contextually-relevant images (such as people, products, etc.) are most often appropriately called inline. However, graphics which make up the visual-design environment are best called using CSS. This not only improves separation of content/design, but it also helps with filtering for devices which do not support CSS because images aren’t downloaded. The benefits include bandwidth reduction, improved performance and enhanced presentation for text-only and aural email clients. When the CSS property background-image is not supported, images must be displayed inline.

Background-position
When background images are supported, support for positioning of said images becomes vital for readability. Background images are often placed inside a block-level element which also contains HTML text. The CSS property background-position helps us position background images so that nearby text doesn’t become unreadable. When positioning is unavailable, accessibility becomes a potential issue with the prospect of unreadability.

Color/background-color
Probably the most fundamental part of visual design is color; it’s the foundation for design. But beyond support for foreground/background colors for the sake of visual design, inconsistent or partial support can cause accessibility problems. When a black background color is eradicated while white text thereon is properly rendered, the result is white text on a white matte.

Descendant selectors
An excellent way to help keep markup clean and to recycle CSS is to use descendant selectors. Without this support, IDs and classes must be applied to every element which needs to be styled. This bloats a file with unnecessary markup and complicates the production process.

Float/clear
The CSS property float is vital to designing with standards-based markup. When tables are removed from the designer’s toolbox, float is the groundwork for layout. Without it, an entire design can collapse. And as elements are floated in a layout, the property clear is there to make things right for any following elements. Clear ensures floated elements do not cloak adjacent content, float and clear go hand-in-hand.

Margin
With no support for margin, a design looks considerably broken. But destroying the aesthetics of an email is just the beginning. When elements are forced together without a buffer, the text therein most often becomes unreadable.

Padding
While a lack of support for padding has fewer ramifications than margin, it is important for similar reasons. Most importantly because of its use in combination with other elements such as background-color, list-style-image and border. When used in combination with said elements, the impact of its absence is multiplied.

Varying link-colors
Linked text throughout an HTML document often resides atop varying background colors, and therefore in order to preserve readability link colors must be changed accordingly. If one parent link color supersedes link definitions which follow it, readability can be compromised. Because this extends beyond aesthetic characteristics we feel it is vitally important for accessibility.

Width/height
Use of width is more common than height, and the latter is often used solely for aesthetic balance (extending background colors, etc.). But both are vitally important to any design as a lack thereof either can cause unreadability and demolish a layout. Width is critically important because the functionality of properties such as float and text-align are dependent upon it. When width is not supported, float becomes irrelevant and right-aligned or centered elements are not positioned respectively because the default width of a block-level element is 100%. And beyond the negative impact on aesthetics, a lack of support for height can lead to problems with readability as floated elements therein aren’t cleared without additional markup.

Normal Priority

Background-position a:hover
Using a:hover to change the position of a background image therein the a tag is a widely used technique for interactivity in standards-based design. It is most often used to change background colors/images for faux buttons and navigation elements, typically comprising HTML text. While not critical to an email design, it enhances an experience with visual cues for linked elements.

Border
A design certainly isn’t going to fall apart when its borders are compromised. But when they are missing or improperly rendered, it’s obvious something isn’t right even if that something can’t be identified.

Font family/size/weight/style
When font properties are not supported, text is still displayed using default font values. While this degradation doesn’t result in unreadable content or inaccessibility, it does compromise design integrity. Most notably when a serif font becomes sans-serif, or vice versa. Fonts are an integral part of a visual design, and therefore proper support for font properties should be a pivotal part of an email client.

Font-family names with quotes
Though many common HTML-font names are defined as single words (Georgia, Arial, etc.), others are defined using more than one word (Trebuchet MS, Lucida Grande, etc.). And per CSS guidelines, fonts with names comprising more than one word must be enveloped in quotes. Web designers are already limited to a small cache of HTML fonts, so removing some from the list dumbs down that list even further. While a lack of support for multiple-word font names isn’t mission critical, it tightens already constrained parameters to which web designers are adhering, regarding HTML fonts.

Font inheritance
An excellent way to help keep markup clean and to recycle CSS is to take advantage of font inheritance. If font styling must be applied to every necessary selector, files are weighed down with unnecessary markup and the production process intensifies with extraneous labor.

Line-height
With a lack of support for line-height, a design hardly falters to a state of unreadability or inaccessibility. But this property allows a design to breathe and increases the efficiency at which someone reads. Thus it adds value when used properly.

List-style-image
A design can be enhanced by dressing up bullets in a UL. The two most popular methods for making this happen are the default list-style-image and an alternate, more controllable method using background-image and padding (view an example of this technique). When list-style-image is defined and then not supported, the degradation is minor in that a default bullet is displayed. However, it’s a modest property which, when supported, can greatly enhance a visual design.

Future Acid Tests

We have made every effort to ensure our acid test was constructed in harmony with how everyday emails might be developed using web standards. Our line of thinking was derived from our experience conducting countless hours worth of tests for a broad array of email components and then having written respective blogs posts to report our findings.

With each post we learn something new both from the actual tests and also from the contribution of comments. And we intend to continue feeding this project with feedback from the global web-design community.

Therefore we welcome any comments you might have whether you are a web designer, an email-client developer, an email newsletter author or even a subscriber to email lists. This project is intended to create a better experience for everyone who creates, sends and receives HTML emails from permission-based lists. So everyone should add their voice. if you feel something isn’t accurate, if you believe we’ve left out something critical or anything else you feel is important to note for future evolutions of the acid test.