Using Empty Table Cells in HTML Emails
Do Empty Cells Display?
Designers often use empty cells in tables to create “pixel perfect” emails, but this method might not be as reliable as you had thought. We performed a number of tests to investigate empty table cells. Our first test checked to see if row and column cells that had color but no content would show up. Check out a sample of the code for our column test below.
One
<table style="background:red">
<tr><td>test</td></tr>
<tr><td style="background:black"></td></tr>
<tr><td>test</td></tr>
</table>
Two
<table style="background:red" cellpadding="0" cellspacing="0">
<tr><td>test</td></tr>
<tr><td style="background:black"></td></tr>
<tr><td>test</td></tr>
</table>
All clients that we tested rendered empty cells with at least a few pixels in width (or height) even if they had no content. If you use the cellpadding=”0″ and cellspacing=”0″ attributes (“Two” in the example above), however, things get a bit more sticky. Most clients won’t show an empty column cell with no cell padding or spacing, but nearly a quarter of the clients we tested did. Take a look at the chart at the bottom to see which ones. Support for empty row cells (with no cell padding or spacing) was also not universal, with about 10% showing them and 90% of clients not showing them.
Most email clients displayed the first two tests as in the image on the left (Example 1). Notice that in test 1, the empty cell with black background is displayed as a thin line with red on either side of it. This is caused by padding, which gets the color of the table itself. With margins and padding removed, however, no cell is visible at all! This doesn’t hold true for all clients. For instance, check out Live Mail’s rendering of the same test, on the right (Example 2).
Do empty cells display borders?
Again, the answer to this one is, “Not always.” Most clients do give borders to empty cells, but some of them do not. In the test below we added the border: 1px solid black property to all td’s in the table. The top-center, middle-center and bottom-left cells are empty of content, and the middle-center cell has a black background color. You can check out the table at the end of this blog post to see exactly which clients show borders on empty cells and which don’t.
Cell Height and Width with Empty Cells
Regardless of margin or padding settings, these attributes seem to work in all email clients. A mobile client might resize your table cells if they don’t fit within its screen. Check out our blog on table sizing and iOS6 here, for an example.
Fillers for Empty Cells
A non-breaking space ( ) is a common filler for otherwise empty cells. This creates a space character which is transparent. For many purposes, this is a good solution. However, when very small cells are used for layout purposes, the non-breaking space will be too big.
Another commonly used filler is <br />, a line-break. This filler doesn’t create a character, but email clients will render the cell with the same height as a regular line of text. Other than Outlook 2003, all email clients should show a table cell with <br /> in it.
A third option is to use an empty div, <div></div>, inside the table cell. An empty div will be displayed on most browsers just like an empty cell would be. This makes the empty div not much of a fix, as it appears to have no effect on how the cells are rendered.
EoA Recommends
We recommend not using empty table cells. Because of the discrepancies among browsers when it comes to displaying the cells, we recommend the use of cell height and/or width values, or colspan, rowspan and padding instead of empty cells. As long as you’re not using borders, this should help you achieve identical layouts in all browsers.
Supporting Research
The first results column below shows whether or not an empty cell with a different background color is visible with margins and padding set to zero. The second column is the same test, but for an empty cell in a row. The third column shows whether or not that client applies a border to empty cells. The last column shows which email clients display a table cell with an empty <div></div> inside it. Results for some clients were inconclusive, showed by a “?” symbol.
| Desktop Clients | ||||
| Clients | Empty Cell Shows? (column, no margin) | Empty Cell Shows? (row, no margin) | Empty Cell Gets Border? | Empty Div Shows? (no margin) |
| Apple Mail 4 | n | n | y | n |
| Apple Mail 5 | n | n | y | n |
| Apple Mail 6 | n | n | y | n |
| Entourage 2004 * | n | n | y | n |
| Entourage 2008 * | n | n | y | n |
| Live Mail | y | n | n | y |
| Lotus Notes 6.5 | y | y | y | y |
| Lotus Notes 7 | y | y | y | y |
| Lotus Notes 8 | y | n | n | y |
| Lotus Notes 8.5 | y | n | n | y |
| Outlook 2003 | y | n | n | y |
| Outlook 2007 | n | y | y | n |
| Outlook 2010 | n | y | y | ? |
| Outlook 2013 | y | y | y | y |
| Outlook Express | y | n | n | y |
| Thunderbird 13 | n | n | n | n |
| Windows Mail | y | n | n | y |
| Android 2.3 | n | n | y | n |
| Android 4 | n | n | y | n |
| Android Gmail 2.2 * | n | n | y | n |
| BlackBerry 9930 | n | n | y | n |
| iPad 5.0 (iOS 5) | n | n | y | n |
| iPad Gmail (iOS 3) | n | n | y | n |
| iPhone 4S (iOS 5) | n | n | y | n |
| iPhone 4S (iOS 6) | n | n | y | n |
| Kindle Fire 2.3 | n | n | y | n |
| AOL | ||||
| Chrome 18 | n | n | y | n |
| Firefox 12 | n | n | n | n |
| Internet Explorer 8 | y | n | n | y |
| Internet Explorer 9 | n | n | y | n |
| Safari 5 | n | n | y | n |
| Gmail | ||||
| Chrome 18 | n | n | y | n |
| Firefox 12 | n | n | y | n |
| Firefox 3.6 | n | n | y | n |
| Internet Explorer 8 | n | n | y | n |
| Internet Explorer 9 | n | n | ? | n |
| Safari 5 | n | n | y | n |
| Hotmail | ||||
| Chrome 18 | n | n | y | n |
| Firefox 12 | n | n | y | n |
| Firefox 3.6 | n | n | y | n |
| Internet Explorer 8 | y | n | n | y |
| Internet Explorer 9 | n | n | y | n |
| Safari 5 | n | n | y | n |
| Outlook.com | ||||
| Chrome 18 | n | n | y | n |
| Firefox 12 | n | n | y | n |
| Firefox 3.6 | n | n | y | n |
| Internet Explorer 8 | y | n | n | y |
| Internet Explorer 9 | n | n | ? | ? |
| Safari 5 | n | n | y | n |
| Yahoo! | ||||
| Chrome 18 | n | n | y | n |
| Firefox 12 | n | n | y | n |
| Firefox 3.6 | n | n | y | n |
| Internet Explorer 8 | n | n | y | n |
| Internet Explorer 9 | n | n | ? | n |
Author: Kyle Lapaglia
Author: Kyle Lapaglia
20 thoughts on “Using Empty Table Cells in HTML Emails”
Comments are closed.
I find it interesting that you recommend using colspans and padding rather than an empty cell with a width defined, which if I read correctly, you say works well. Colspans and padding have some sketchy support. Generally I see our clients using empty cells with a defined width with good success, and I would think it’d be the better solution in this case? Am I off the mark here?
Davida,
What clients have you had trouble with colspan and padding in? We had thought those attributes were well supported, but if not we’d love to know about it.
Regards,
Geoff Phillips
Email on Acid
We’ve used empty cells with at least a width on them to great success. We definitely avoid colspan and padding whenever possible, opting for more and nested tables instead (sacrificing clean code for solid structure.)
I never had problems with colspans, although i for myself dont like using them. A lot of mailing-clients tend to be rather forgiving if you make mistakes like not using the same number of cells in a row, so its easy to miss it if you do mess up.
Personally I use paddings the most, although you have to be really careful with “reverse” definition of paddings in Outlook. Especially when working with borders.
For this reason you see people using transparent spacer gifs in table cells a lot. Obviously those are a hassle with image-blocking but using them is an easy way to make sure a cell has exactly the size you want it to have.
To create spacing, I use empty TDs and assign values for height and/or width, for example:
Also, I don’t use padding-left and padding-right in TDs, but I do use padding-top and padding-bottom.
As far as I know, these work well for me. Somehow, the use of spacers screws things up with some clients, including (I believe) Yahoo. Definitely I’d stay away from using DIVs.
When properly coded, colspans, rowspans, spacer images & padding shouldn’t be used.
I’ve been using this with great success (so far):
When I need a horizontal space:
When I need a vertical space:
I would like to see someone prove that colspan has a lack of support. I have been coding emails since 2006 and I used to do a lot of table-based layouts before that – since as early as 2002 – and as long as you understand how to properly use colspan, you shouldn’t have any problems.
I encourage and welcome anyone to challenge me on this – we’re all here to learn, after all.
“font-size:1px; line-height:1px;” along with non-breaking spaces are no longer necessary as a fix for Outlook 2013. See here: https://www.campaignmonitor.com/forums/topic/7376/outlook-2013-cell-height-bug-solution/
Also, colspans/rowspans create a situation where edits to existing templates can be much trickier, as you now need to keep track of their widths / heights/ etc. You also have too many cases of end users trying to make basic changes and not understanding how the widths & heights need to add up perfectly. When you combine these challenges with a complex longer layout, it’s just not worth the hassle if future changes need to be made.
Why battle to save a kb when you can create more headaches down the road? I code anywhere from 6-10 emails a day, including updates to older templates, and my job is MUCH easier when colspans/rowspans aren’t involved.
BTW – I’ve been coding since 1994, back before the internet was mainstream. I dream in pixels & tables.
@Brian: Thanks for the update on the Outlook 2013 issue.
I get what you’re saying about colspans and rowspans – but I only asked that someone prove to me that ESPs lack support for it.
I completely agree that using them CAN make it harder to manage. Especially if the person editing them is inexperienced or the person who built it went overboard.
One method I’ve been using the past few years is to have stacked tables rather than one big table or several nested tables. In doing this, it makes it a LOT easier to manage. I picked up this habit from a co-worker in 2010. I had previously thought that having so many (stacked) tables was Bad News Bears – but we work with several third parties like Acxiom and CheetahMail at Campbell Ewald, and none of them have complained about it (to my knowledge). I have been meaning to do some research on it to make sure it doesn’t have an impact on spam ratings or download time or something, though.
Anyways… if you take the stacked tables approach and you are using colspans sparingly, then you should not have too many problems when someone else has to go in and edit the layout. At the most, I will use colspans in a small table, and only on rare occasion.
I’m not saying go nuts with colspans – I’m just trying to argue that they CAN be used. Davida said there is “sketchy support” – but I would like him to cite his sources for that information.
As a final note – I just want to say that I did not mean to insult anyone. This isn’t a competition. I’m assuming we’re all here because we wanted to learn something. With that in mind… I simply wanted to get an open discussion going about colspans.
I’m sure you’ve all coded many successful emails (as have I)… but in the end all that matters is whether the client is happy or not.
Thank you for taking your time to respond to me, Brian. I would be interested in connecting with you outside of this little thread. Feel free to connect with me: http://linkedin.com/in/erikwoods
Erik, yeah, I became curious too. I only avoided them because “I’d heard..” I’ve set up some tests in my EoA to see if I can actually find a breakdown of support.
Although I tend to agree with Brian Thies, I basically just dislike colspans/rowspans in general and avoid them, but if they are supported across the board there’s no reason not to use them if they are your bag.
However, I still take issue that they would be considered a superior option to empty
OK I did run a test today of some code that included some simple tables with rowspans and colspans. My tests with tables with defined widths on
Davida,
I tend to agree with Brian, as well. I perhaps took the wrong approach to my initial response and I realize that now. :-p
I also have a hard time considering the colspan/padding solution described in this article as a good alternative. I’m sure it works, but I don’t ever run into a situation where I cannot set a width or height on an empty
I only wanted to say that colspan does not have a lack of support – as far as I know. To say that…. a lot of people seem to think that it’s not good, when actually it works fine, if you want to make things complicated or hard to manage.
Sorry for the confusion! Glad to see that we can have a pleasant back-and-forth on this sort of thing between fellow developers. 😀
Davida,
It seems that my last comment was either moderated and accepted AFTER yours was, or I wrote my response to your first message on 2/15, before your second post on 2/15 was posted.
No matter – I’m glad you have circled back with me on that. I wasn’t trying to call you out on it – I was just trying to figure out if there was something I should be aware of that I was not already.
Thanks again.
Hey Erik,
I’m glad you called me on it, it made me go do real tests rather than rely on hearsay. I’m also very glad we could have an amicable discussion on it, nice to be involved in a comment thread where everyone’s acting like adults.
Will agree with Brian on this one, except for the padding comment. Colspans I can deal with if I HAVE too, but rowspans… no thanks.
we can use:
or 1px spacer image instead.
Colspan and rowspan work fine, you just need to be aware of the Outlook quirk: http://stackoverflow.com/questions/9697788/html-email-is-colspan-allowed/16964122#16964122
I also think there is a need for having them in your toolbox as certain layouts can not be accomplished without them. Example:
Even though I’m guilty (lazy) of using padding, I think using spacer cells with in them is actually better supported. I did find it interesting that
also works.
I believe Blackberry 5 OS doesn’t like padding. I’ve also noticed some inconsistencies with the padding being removed when the email is forwarded out of Outlook.
Looks like the no-break-space and br were taken literally in the 2nd to last paragraph from my post above…
Is there any documentation on how to include code examples here?
John,
I think if you use HTML entities instead of the actual characters it will appear correctly. Sorry about that!
I have found the following works, and I have yet to see any issues with it. I really did not want to use transparent spacer gif images.
I use the following code for empty table cells to control width or height in pixel perfect designs, which my client requires.
Thankfully Lotus Notes is one email client I do not need to support.
This is for controlling width spacing in email designs:
This is for controlling height spacing in email designs:
Chad Lummis