Tables in HTML Emails: Nesting, Padding and Widths, Oh My

Published July 19, 2007 by Mark Wyner

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 table widths, td widths, 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:

<table cellspacing="0" cellpadding="0" border="0" width="400">
<tr>
<td width="100"></td>
<td width="300"></td>
</tr>
</table>

Just as intended, the resulting width of this table is 400 pixels and the width of the columns are 100 and 300 pixels:

[screen shot]

But when some padding is added—via either CSS or HTML—the widths of the columns are compromised:

However, when 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">
<tr>
<td width="80"></td>
<td width="280"></td>
</tr>
</table>

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.

Nested Tables

If a 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 table behaves appropriately.
  • Applying widths to td tags 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 table with 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).

Clients Tested

Webmail

  • Yahoo Mail
  • Yahoo Mail Beta
  • Windows Live Hotmail (old)
  • Windows Live Hotmail (new)
  • Gmail
  • .Mac
  • AOL

Desktop

  • Apple Mail
  • Thunderbird
  • Outlook 2007
  • Outlook 2003
  • Outlook Express
  • Eudora
  • 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.

22 Comments

Posted in:

  1. Damien Buckley
    July 19, 2007 2:19pm

    Mark you’re scaring me. Tables send a shudder down my spine. Brrr

  2. Mark Wyner
    July 19, 2007 3:04pm

    Campaign Monitor team member

    I know, Damien. I know. I took a hit for the team and went against the grain for the common good. At least I hope that’s what happened.

  3. Darren Nicholls
    July 19, 2007 9:14pm

    Whom, interesting comments about padding etc. Though the comments on using tables in the first place is a bit smug for my liking. Have you passed the same judgement to the new MailBuild templates, which as you’ve probably seen are built around tables.

  4. Dave Greiner
    July 19, 2007 9:29pm

    Darren, Mark actually designed all the new templates himself. He’s got both sides of the table covered (how good was that pun).

  5. Jason Powell
    July 20, 2007 1:36am

    Mark, Interesting differences with padding and nesting. Thanks for the tips. I’m concerned about the design integrity comment. I can see that if a design was “broken” because tables didnt display correctly, then that could harm integrity of a design, or even a brand, but if you could provide some examples of how “standards compliant” code outweights design integrity I’d be very interested in that. Haven’t you found as many display differences among email clients when using CSS positioning, etc.?

  6. Jerk
    July 20, 2007 5:08am

    Mark, I understand your bent for standards and completely agree. I adhere strictly on every website I can. However, I have much trouble coming anywhere -close- to standards with mail. The designs I am working on require cross-platform support (pretty much everything but Notes and Eudora) with a complex mixing of copy and design.

    I am in the position where I essentially get handed a design and and I need as close a 100% translation as possible, something I just don’t think is possible without violating standards in the wild west of email client compatibility.

    How do you stick to standards? Do you compromise on design or have some neat tricks?...Magic wand?

  7. Mark Wyner
    July 20, 2007 6:05am

    Campaign Monitor team member

    @ Darren:

    I’m sorry you feel my comments about the use of tables are smug. I try to author these articles with a light sense of humor and certainly don’t intend to imply that I’m better than anyone else. I am simply dedicated to web standards with my own work, and when I share information that violates web standards I have a level of guilt about it.

    I feel the information I learn is worth sharing because I understand that others aren’t so lucky about being able to strictly adhere to web standards or even may have little concern about doing so. But this is a scenario which breeds people who say things like “I thought you are a web standards guy. You’re the devil for crossing the line.” And thus my preface about using tables. Take it with a grain of salt and you’ll be just fine.

    @ David:

    Settle down over there. You’re going to poke your eye out with those puns.

    @ Jason:

    I’m glad you appreciate the tips. And you’re welcome.

    Regarding your CSS vs. tables concerns, this debate is at the core of standards-based markup. For more information about how a 100% web standards approach works in the email environment, you might want to read an article I wrote for Campaign Monitor a while back. That article answers your question about design inconsistencies with CSS. Though, in short, the answer is “yes, though I even find more inconsistencies with CSS layouts.”

    I don’t need to go into the general benefits of using web standards because that information can be found all over the web, but know that with HTML emails these benefits are parallel. And I encourage my clients to embrace accessibility over design integrity because I believe accessibility is more important than a visual brand. I certainly understand why some people may disagree and I’m not implying that my preference is absolute. But I do work to help my clients understand the pros and cons of using one method over another, and most of the time they understand and agree to grin and bear the lapse of design in CSS-incapable clients.

    @ Jerk:

    Why “jerk”? Your comments are just the opposite.

    I wish I had a magic wand and some neat tricks to ensure design integrity with pure CSS layouts in the email environment. More so, I wish I had the power to convince Google and Microsoft that web standards are important. But the reality is that to build HTML emails with web standards markup, we must sacrifice design integrity. We did this when most browsers offered poor support for CSS, and eventually they came to. Nearly every popular, modern desktop-browser now offers amazing CSS support (IE quirks withstanding). I fought that battle then with browsers and I am determined to fight the same battle now with email clients. That’s simply my philosophy on the matter.

  8. Kilgore Trout
    July 20, 2007 8:26am

    Why all the fuss over tables in emails? If you know what you’re doing and it works then why use CSS that falls apart in Outlook 07 and Live Mail. Tables and shims forever!

  9. Toemouse
    July 20, 2007 9:38am

    I Agree with Kilgore Trout. When it comes to html emails Table-me-up. But as for the shim, you should be ashamed for even admitting to the use of them, let alone the actualy practice of doing so!

  10. Bill NZ
    July 20, 2007 11:53am

    Unfortunately, for 90% of my clients (agencies) design integrity is paramount, so I have to keep the CSS to a minimum (text formatting only).  And even that doesn’t guarantee that the design will stand up (the most popular ISP in New Zealand, Xtra, has webmail that drops all CSS text attributes and renders everything as 11pt Verdana Black).

    Late last year, I thought we were coming along nicely as the most popular desktop email clients handled CSS reasonably well, with the exception of Hotmail and Gmail.  Then Outlook 2007 and Vista Mail came along, and sent us back to the late 90’s as far as standards-compliance goes. 

    So, it was back to tables for us.  This means CSS as close to the element as possible (since some clients mess up the cascade), sparing use of padding and margins, and no more CSS backgrounds.  I find that on the majority of webmail clients TD padding is ignored, and collapses making the design look cramped (and DIVs are out of the question as any useful styles that you would put on a DIV are ignored on too many clients).

    I long for the day that I can make standards-compliant emails, but I’m afraid we’re still about 5 years (or longer if MS gets its way) before I can safely use CSS effectively.

  11. Darren Nicholls
    July 25, 2007 2:36am

    @Mark, I was having a bad day so perhaps I was being a touch sensitive. I’m drinking Ginger & Lemon tea to chillout!

  12. chris
    July 28, 2007 3:24pm

    Hey there,

    I know that we always talk about using tables in emails/webpages etc as bad, but when we talk about it breaking standards, we’re not talking about causing HTML or XHTML to be invalid, are we?

    Can someone please clarify this, for me. Thanks.

  13. Mark Wyner
    July 31, 2007 9:10am

    Campaign Monitor team member

    @Killgore Trout

    Why all the fuss over tables in emails? If you know what you’re doing and it works then why use CSS that falls apart in Outlook 07 and Live Mail.

    Because accessibility should be more important than ensuring corporate standards.

    @Bill NZ

    Thanks for the info about Xtra. This sounds just like the old .Mac problem I mentioned in another article, which is now irrelevant with the new, worse .Mac webmail client.

    @Darren

    Ha, ha. No worries, Darren. Enjoy your relaxing tea.

    @Chris

    We could do worse things to a website/email than use invalid markup. I validate all of my websites, but there are occasions when the validation refers to something that hasn’t been considered from a human perspective. The validator is, after all, a computer program. So when we have a URL with ampersands the page is invalid. But does it really matter that there’s an ampersand in a URL that hasn’t been encoded? Possibly, but I know I’ve never encountered such a problem. And I also haven’t read every line of every W3C specification so maybe I’ve missed this.

    The whole point is to ensure that our content is accessible to everyone, irrespective of their browsing device. When we get a green light from a computer program that validates our markup we’re in great shape. Validators are important tools. But it’s simply a tool. What’s most important is that we cater to as many people as possible even if we make a few sacrifices for the majority.

    I often think of wheelchair ramps because they’re an obvious example. How many ramps have you seen which hinder the aesthetic of a building? I’ve been many. But we put the ramps in place and suck it up because we welcome those who can’t enter a building walking on their own two feet. And consider having to wait through a message in a telephone system which states “Para oír sus opciones en español, por favor prensa 1” (To hear your options in Spanish, please press 1). I’m happy to wait an extra 10 seconds for this message to play out because it means it is available to someone who doesn’t speak English.

    I hope that answers your question.

  14. Kilgore Trout
    August 9, 2007 11:51am

    Mark, using tables ensures accessibility in a vast cross section of email clients, like Outlook. CSS sort of does, but not compared to tables. And Toemouse, I dont apologize for using shims. They make my tables tight as a weave. Respect the shim.

  15. Anna
    August 22, 2007 1:46pm

    Thanks for the clear example of table widths versus column widths and cross platform testing!

  16. Forest
    October 2, 2007 2:52am

    Interesting analogy about including Spanish in automated telephone systems.  One could also argue that this is akin to using browser hacks or HTML tricks to accommodate multiple software programs, and that having a standard national language would simplify the automated system design process, just as having web standards simplifies the web design process.  I dont think the analogy works for web usability, because there are no obvious (to me) software standards issues with telephones.  They just work.  Multiple language options can also be added to websites, but that doesn’t have much to do with the browsing software or the software’s compliance to web standards.  I agree that accessibility is important, but I must weigh it on a client by client basis.  Now if I could only get my HTML email tables to format correctly…

  17. dave
    November 7, 2007 10:24am

    I’m curious about cellspacing. I’ve recently tried using it and it seems to work great across the board except in the new gmail code. Have you ran into this?

  18. jenny
    December 14, 2007 5:25pm

    I second the last comment about cellspacing in gmail--but only on the Mac platform.  I’ve always tested my e-mails before deployment, and now I’m noticing that old e-mails I had sent are showing up formatted badly--cellspacing-collapsed and padding disappeared.  But only on gmail viewed in Firefox, Camino, or Safari on the Mac.  But perfectly fine on PC’s--outlook, gmail, hotmail, yahoo, comcast.  What’s up? By the way, I am of the camp that believes in consistent appearance across all e-mail providers rather than sticking strictly to standards… so yes, I use tables in my html e-mails.

  19. Dave Greiner
    December 16, 2007 1:00pm

    Jenny, we just wrote about the different versions of Gmail here. There are actually 4 different versions to content with, all with different rendering.

  20. DAn
    February 27, 2008 2:41am

    I have tested these 3 cases and table 2 and table 3 display idenically [as you describe it in case 2]. Any ideas?

  21. DAn
    February 27, 2008 3:21am

    Ignore my previous message. I made a mistake.
    Great article but I think we have better control using empty cells than using padding.

  22. Rules
    August 24, 2008 10:53pm

    I’m concerned about the design integrity comment. I can see that if a design was “broken” because tables didnt display correctly, then that could harm integrity of a design, or even a brand, but if you could provide some examples of how “standards compliant” code outweights design integrity I’d be very interested in that.

Comments for this entry are closed.

Browse the Blog

  1. Interviews & Buzz (110)
  2. New Features & Updates (150)
  3. Observations & Answers (153)
  4. Tips & Resources (293)

Explore the Email Gallery

@thisisnation Fire through a link and we'll check it out. ^DG

Follow us on Twitter