By Administrator on 19th July 2007
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.
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:
tdtags that also have CSS or HTML padding creates confusion across the board. Nearly every client renders the widths in its own unique fashion.
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).
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.
Sign up for free.
Then send campaigns for as little as $9/month