Alternative Table Structure for Flexible HTML Emails

in Front-end

HTML emails can be incredibly impactful when they’re done the right way, and now there’s a new (and exciting) way to write tables for HTML emails. So today, I’m going to compare it with existing best practices, showing you the pros and neutrals (no cons!) for you to decide if you want to use them in your workflow. I also want to give a big hat tip to Mark Robbins from Rebelmail for working this one out.

Rest in Peace, Ghost Tables

If you’re all like, “What’s a ghost table?” they’re part of a technique either dubbed spongy or hybrid, and they have served us well for a couple of years of HTML email creation. I taught them in level 5 of Unmasking HTML Emails as a way of achieving a fixed width for a table in clients that do not support max-width in CSS. I was standing on the shoulders of giants then, and I am again as I write this post. (It’s not just because I’m short — Fabio Carneiro, Mike Ragan, and Mark Robbins contribute so much to the HTML email community.)

For this round, it was Mark’s turn to change the way we write table HTML in The Table of Your Dreams. The basic premise of his technique is to use a fixed-width table cell to control the max-width of a table that is set to 100% width. This works because of the ways that table cell widths are implemented. A plain-talk version of the spec is along the lines of, “Take up to x amount of space if you have it, but squish if you don’t.” It’s like the O.G. implementation of max-width in CSS, which doesn’t have support in Outlook apps.

There’s still a bit of client hacking in this new technique. Some clients won’t honor the additional cells if they are empty, so there needs to be a &​nbsp; in the cell. With that in play, some clients will add spacing to the cell based on a single character. To avoid that, each cell needs to have font-size: 0; as well.

<!-- CONTENT: {name} -->
<table border="0" cellspacing="0" cellpadding="0" width="100%">
      <td style="font-size: 0;">&​nbsp;</td>
      <td width="480">

          <!-- Content goes here -->

      <td style="font-size: 0;">&​nbsp;</td>

More Efficient Code

Upon reading Mark’s post, I was so excited about all the code I was going to be saving. Those ghost tables add 10 lines of code to each fixed-width table that I use in the way that I format my HTML.


I quickly found out there is a trade-off, which I referred to as a “neutral” instead of a con. The extra cells that need to be added cut into the line savings. (I save a little by keeping the closing td on the same line for empty cells.)


For small amounts of content, you could get away with the additional cells. For emails with at least three rows of content, I’d suggest nesting a table. This example is enough content to make one wrapper table more efficient in lines of code and authoring.


The savings aren’t game-changing, but you’re not using conditional comments anymore. This approach feels less like a hack and is delivering the same code to each client.

Example Breakdown

As a quick way to see how this impacts an email, I created a little announcement for Ghost Tables, Inc. Click “Edit Email” to view the code.

76 lines using ghost tables

73 lines using empty cells in content

64 lines using one wrapper table with empty cells

And now for me, it’s “buh bye,” ghost tables. The more efficient code with less hacks is enough of a driver to update my snippets for future emails and to update existing ones as I can.


Of course, support is always a concern, but I’ve found it tests perfectly — and the variation of placement of the ghost is me playing with margin for the cool clients. As always, you’ll have to experiment with it and decide if it works within your workflow. Which way do you prefer? Let me know in the comments section below!

Code School

Code School teaches web technologies in the comfort of your browser with video lessons, coding challenges, and screencasts. We strive to help you learn by doing.


About the Author

Dan Denney

I’m a seriously good copy and paster. Front-end dev for @codeschool, lover of all things web design/dev related and founder of @frontendconf.

Might We Suggest