Disclaimer: This post was originally published in 2015. The email clients listed and information regarding them may be out of date.
I would like to preface this article by stating that I use standards-based markup to build my HTML emails and my websites. But for those of you who are familiar with other articles posted here at Campaign Monitor about HTML emails will know that standards-based markup results in formatting not unlike rich-text format (RTF) in many popular email clients. I’m comfortable with this and so are my clients. Well, they are once they learn about how web standards ensures accessibility and cross client/platform/device content-compatibility and helps emails reach legitimate subscribers without being eradicated by spam filters.
But not every web designer has the grace and charm of Mark Wyner, and therefore many face clients and bosses who demand they build HTML emails for design integrity at any cost. (Oh how this reeks of the “browsers vs. web-standards” battles of old.)
So for those of you who must use
tables in your HTML emails, I have some information about how they perform across the board. I ran some tests and discovered that, while I couldn’t find a perfect solution, I did manage to collect some useful tips to make your
tables behave for the most part.
Table math, meet box-model math
So it turns out that when one places
td padding and CSS padding into a blender, the results are quite chaotic. Inconsistent, to the say the least. Take, for example, the following
<table cellspacing="0" cellpadding="0" border="0" width="400">
Just as intended, the resulting width of this
table is 400 pixels and the width of the columns are 100 and 300 pixels:
But when some padding is added—via either CSS or HTML—the widths of the columns are compromised:
table width is kissed good bye, the results are not unlike a CSS box model. If padding is added to the original example and the
table width is removed, the code looks like this:
<table cellspacing="0" cellpadding="10" border="0">
And, as intended, the resulting widths are correct for both the
table and the columns:
But note how the
td widths were reduced to accommodate the new padding. This is just like the CSS box model in which 100 pixels wide + 10 pixels padding = 120 pixels total.
table is nested inside another, the aforementioned rules apply with the exception of a couple important variances:
- Yahoo Mail (new), Gmail, Outlook 2007 and Eudora apply extra width to account for borders. But only when they are nested, as the parent
- Applying widths to
tdtags that also have CSS or HTML padding creates confusion across the board. Nearly every client renders the widths in its own unique fashion.
- Even without any borders there are variances in width by 2–4 pixels for a nested
tablewith two columns. My tests were inconclusive as to the rhyme and reason behind this unnatural phenomenon. Just know that pixel perfect isn’t an option (unless there is some hidden secret behind this).
- Yahoo Mail
- Yahoo Mail Beta
- Windows Live Hotmail (old)
- Windows Live Hotmail (new)
- Apple Mail
- Outlook 2007
- Outlook 2003
- Outlook Express
- Lotus Notes
So there you have it. Please do your best to educate your clients/bosses about how the benefits of standards-based markup far outweigh design integrity across the board. But if you fall short of convincing them and are forced to use
tables for layout, take note of the lessons outlined herein. You’ll save yourself a nasty headache.