HTML Tables in Email: What could possibly go wrong?

[ 0 By

If you’ve been in the email industry for any amount of time, you’ve likely experienced a number of problems with your email campaigns. From missing images to deliverability problems, email marketing is fraught with challenges. Something you may not have considered, though, is what can go wrong with the tables—the actual code—that is at the foundation of your emails.

Unfortunately, there is a lot that can go wrong with HTML tables. Today, we wanted to break down some of the most common problems seen with HTML tables and give you a few tips for ensuring you don’t encounter the same problems in your own emails.

Why we use tables

First, a quick refresher on why we use HTML tables for coding emails. As we discussed in the past, email marketing campaigns require their own special coding considerations. While the web and email are built on the same technologies (HTML and CSS), email applications don’t adhere to the same standards as web browsers. Each email application has its own rendering engine which determines what code is supported and how emails are displayed. The bad news for us is that all of those rendering engines support different HTML tags and CSS properties.

Because of this, we largely can’t use the same coding principles used in web design. To ensure that emails display properly across most email clients, we have to use HTML tables to create the structure of an email campaign.

Although this has been changing recently, especially with Gmail’s major update last year, some email clients still don’t support a lot of HTML and CSS. The most notable: Microsoft’s Outlook family of email clients, which use Microsoft Word as their rendering engine. Since Outlook is still hugely popular (currently #5 on our Email Client Market Share tracker), email designers still have to use tables in some capacity if they want their campaigns to display properly for subscribers.

And when we have to rely on HTML tables, there are a number of things that can go wrong…

Making things complicated

One of the most common problems we see with using tables is overly complex layouts. This is especially true for legacy email templates that haven’t been updated in a few years.

Until somewhat recently, most emails were built with a lot of tables. Tables within tables within tables—a practice known as nesting.

Nesting tables within tables can only go so far before introducing problems.
Nesting tables within tables can only go so far before introducing problems.

When you nest multiple tables within another table, you’re likely to introduce problems within your code. It’s very easy to accidentally put a table in the wrong place or paste over an essential HTML tag when shifting things around. And for some clients (looking at you, Lotus Notes), you can see emails render poorly when you nest tables too deeply. It’s for this reason we recommend building emails with a modular approach, something our friend Brian Graves wrote about. And try to keep nested tables to a minimum. Nesting tables is nearly unavoidable, but keeping the nesting depth to 4-6 tables max will help avoid any problems.

Similar to complex nesting, overly complex designs can be problematic, too. It’s not uncommon to see multiple column emails, but when you start adding too many columns to an email, you’re setting yourself up for potential failure.

Cramming too many columns into an email can create problems, too.
Cramming too many columns into an email can create problems, too.

Some email clients have problems with even basic math. Certain versions of Microsoft Outlook are known to add extra spacing to table columns, breaking email layouts. While you may think that using four table cells set to 25% widths makes sense, Outlook will add extra space to those cells and cause the layout to be wider than 100%. The resulting email will drop some of those cells onto their own row, ruining your well-designed, perfectly-planned email campaign.

Keeping your email layouts simple helps to avoid potential problems with your campaigns and keeps your subscribers happy.

Missing tags

Emails typically have a lot of code in them. And most email teams work on very quick, tight schedules. This combination can lead to mistakes that can ruin an email campaign.

As a quick refresher, let’s look at how HTML is written. HTML consists of tags that surround content. In most cases, proper markup requires both an opening and closing tag. Take this HTML table as an example:

<table>
  <tr>
    <td>
    </td>
  </tr>
  <tr>
    <td>
    </td>
  </tr>
  <tr>
    <td>
    </td>
  </tr>
</table>

You can see that there are three different tags: The table, table row, and table cell. These tags are opened, and then closed (denoted with the / symbol).

Although HTML is a forgiving markup language, email clients and their rendering engines often choke when HTML tags are missing. Unfortunately, missing closing tags is an all-too-common problem in emails. Those fast turnaround times can lead to email designers coding too fast and forgetting to close out a table, row, or cell. While this can be fine in some clients, in others it will lead to broken campaigns.

Tools like the W3C Markup Validation Service can help identify any missing tags. Missing tags and improperly formed markup are also why we recommend using email templates or tools like Builder’s Partials and Snippets to help create emails. They not only help ensure that your code is well-written and properly tested, but have the added benefit of speeding up your workflow—allowing you to hit those tight deadlines and keep your team happy.

Missing attributes

Just like missing tags can cause problems, missing HTML attributes on tables can lead to funky looking designs.

HTML attributes are additional properties that can be set on HTML tags. These properties control things like element widths and heights, alignment, and even spacing. Unexpected spacing around table cells is one of the most common problems you’ll see with HTML tables.

Nearly all email applications (and web browsers) add their own styles to HTML tables. HTML tables are traditionally used to display tabular data and weren’t originally intended for laying out and designing content. Because of this, we need to override the default behavior of browsers and email applications to ensure tables display properly.

By adding in the cellspacing and cellpadding attributes to the table—and setting both to zero—we can be sure no email clients will add extra space to or around any table cells.

<table cellpadding="0" cellspacing="0">
</table>

Likewise, if you are encountering problems with table widths or the alignment of table content, you should look to make sure that you didn’t forget the width or align attributes on tables or table cells.

Learn how to troubleshoot

Want to learn how to troubleshoot your own email campaigns and avoid any embarrassing problems for your subscribers? Join us at Litmus Live for a full workshop on troubleshooting email like a pro. We’ll go over the most common email pitfalls, their solutions, and the best methods for troubleshooting campaigns.

Get your Litmus Live tickets!

Register today to celebrate email with us!

Register now →