The Litmus Community is the place for email designers and marketers to learn, grow, and educate each other about everything email.

What's the benefit of using multiple tables over TR/TDs?

Kara Christos
posted 2015-01-05 17:07:57

Hi folks,

I just started in a new position where I am managing templates that have already been created. Of course, there is a list of issues that need to be resolved and so I'm spending a lot of time trying to figure out someone else's (messy) code to find solutions.

As it stands, the templates are structured with each piece of content in its own table, with the entire block of content in another wrapper table. Is there any benefit to doing this over having a single table with content split into TR/TDs?

Looking for some feedback before I start jumping in and changing things. I appreciate any insight!

I usually favor the multiple, stacked tables approach over a single table and multiple table rows and cells. Basically, each new section in a campaign has its own wrapper table, so for a typical email, you would see it laid out as follows:

Header

Hero/Featured Section

Article Section

Article Section

Footer

Keeping different content types in their own modular tables allows me to build out different layouts and reuse sections very, very easily. It also makes troubleshooting problems a lot easier to, as you can quickly add and remove sections to see what's going wrong, allowing you to focus on the problem instead of spending time tracking down the actual problem as is often the case when single-table designs start to get complicated.

You could argue that it's just as easy to swap out table rows and cells in a single-table design, but I'd counter that it's way more likely that a tag will get lost in the shuffle that way and your entire design will break, not just a section of the email.

Thanks! So that makes it seem like almost a personal coding preference I suppose.

One thing that is on my list to fix is that when a user forwards an email from Outlook (and maybe other platforms, Outlook is our big one here) white space gets added between the tables, making the entire email look broken. Converting from tables to rows fixes this issue but I of course don't want to fix one thing while breaking five others,

The same approach I take. Working in a team, a modular approach with tables for each email section is a lot easier to have when it comes to creating new emails in terms of time too. Create your modules, comment them accordingly, and then whichever team member can dip in and out and grab the module they need.

Having several stacked tables can get a little repetitive in terms of the code - you'll be repeating stuff a fair few times. But I'd rather sacrifice that for a nice modular system.

One of the major problems with using a single table is that you are limited to tables that are 1800px long. Go above that and Outlook 07-13 forcibly splits your table in two, which can have disastrous results.

I have emails that are not broken up into tables for each section, but rather each <tr> is a labelled section within one table, and this hasn't happened in emails greater in length than 1800px. One email I recently did was almost 4000px in length (according to Chrome)... didn't split anywhere.

Good to know that, was wondering what the exact pixel was to those page breaks.
Having to close the table up and reopen it like this can be tricky:
<!--[if (gte mso 9)|(IE)]>
</table>
</td>
</tr>
</table>
<table width="100%" border="0" cellpadding="0" cellspacing="0" align="center">
<tr>
<td width="100%" valign="top" bgcolor="#ffffff">
<table width="650" border="0" align="center" cellpadding="0" cellspacing="0" class="deviceWidth">
<![endif]-->

I try to view emails in terms of Jenga or Legos. I want to be able to slide parts out and put parts on top or in easily and have everything fit together with as minimal force as possible. So having each section in it's own table (as Jason pointed out) is really the way to go. I used to program in one large table and it became such a mess that to fix something became nearly impossible without recoding the whole thing.

So I'd stick with that approach and try once you figure out a section putting comments in to better help identify things. I put tons of comments in my code labeling sections and rows and tables so I can easily go in and find and change things as well as others that might not be codes but have to get in once in a while to update something.

Join the Litmus Community

Sign up to Community

Get more out of your Litmus account

Your free Community account includes access to the Litmus Community, as well as limited access to Litmus Builder. Check out the entire Litmus Email Creative Platform when you sign up for a free 7-day trial.