Creating spacing in HTML emails has always been a surprisingly tricky topic. What should be a simple task is made infinitely more complex by the lack of email client standards. You'll also find that all email developers have their own little tricks to creating space. In this post we'll have a look at some of the most popular methods for creating spacing, the pros and cons of these methods, and the email client support.
The cellpadding HTML attribute specifies the space, in pixels, between the cell wall and the cell content. We apply it simply by adding it to our tables with HTML like so;
The biggest advantage to using cellpadding is the support. HTML tables are, very obviously, widely supported across all email clients. That means any email client that supports table will also support the cellpadding function. The main issue with using cellpadding is the lack of ability to override it. When using heights, padding, or any CSS code we can override it with media queries. With cellpadding, we don't have the ability to do that because it's an HTML attribute, not CSS.
Where I use cellpadding
I often use Cellpadding in my email code. I tend to use it in places I know I will not need to change the cellpadding for different email clients or devices. For example, adding a guttering around an entire email container.
When I use the term empty cells, I'm referring to empty <tds> that we can add to our code to force spacing around content. For example, this is how you would use it to add the 20px spacing we've been using in this post.
<table border="0" cellpadding="0" cellspacing="0"> <tr> <td colspan="3" height="20"></td> </tr> <tr> <td width="20"></td> <td align="left" style="font-size:16px; color:#000001; font-family:serif;"> Content goes here </td> <td width="20"></td> </tr> <tr> <td colspan="3" height="20"></td> </tr> </table>
The biggest issue with this spacing method compared to other methods is that it doesn't always work! As you can see from our blog back in 2013, empty table cells don't always retain their height.
Another problem is the amount of code to write. Rather than simply specifying one bit of HTML or CSS, we have to code an entire table structure. Another negative consideration is the complication of mobile optimisation; the way to create this as a mobile email is to either hide the cells completely or make new classes to control the width and height of these spacing cells. Both of these methods require media query support. The final mark against this method the fact that it requires exact pixel widths, making it not suitable for Fluid Hybrid emails.
Where I use empty cells
I do not use empty cells, unless forcing height between table cells. The reason being that I likely won't need to change a 20 pixel height divider. You can read more about using empty cells here.
One of the simplest methods of adding spacing, the line break. See below for implementation.
<img src="http://placehold.it/600x150" style="display:block;" border="0"> <br><br> Content goes here
As you can see, you add breaks inside of the content HTML. Unfortunately, this method is largely unused except for adding spacing between text or forcing line returns in your content. Various email clients are known to read the linebreaks at different height, making it virtually impossible to create a pixel perfect HTML email.
Where I use breaks
I only use breaks to break copy (text) in the email content, I do not use it force spacing in other places.
Part of the CSS box model, padding a common method used in web development for creating spacing and often used in email development too. In the past, padding has been a big headache for email developers. However, we've seen over the last year or two that companies are consolidating their email efforts, such as Microsoft switching the Outlook.com rendering engine to the Office 365 rendering engine. This opens the door for us as developers to revisit padding.
Above, you can see how simple it is to implement; just a bit of inline CSS and we're away. The big advantage to this, as mentioned above in the Cellpadding section, is the ability to override this in the head of the email. This means that, for example, we could use media queries to switch 30 pixel padding on desktop to 10 pixel padding on mobile to take up less screen real-estate. With Gmail's recent announcement of support for media queries, this is a very big plus.
On the other side of the coin, there are a few considerations when using padding in HTML email. It's best to stick to using padding on table cells, rather than on tables, for ease of use and troubleshooting. Outlook has also been known to throw a bit of a tantrum when using padding on paragraph, div or anchor tags.
Where I use padding
Anywhere I need to add padding that could change dynamically I add padding. For me, it comes down to a choice of using padding and cellpadding to force spacing.
Another part of the CSS box model, margin is another common method used in web development to add spacing. Though, in my opinion, lesser used in email development. This is how you would implement margins:
Margin works by adding spacing outside of the border in a CSS box model, compared to padding which will add it inside the border. Historically, margins have always been tricky. But, much like padding, the efforts by email companies to modernise their rendering engines could well lead to a resurgence of margin in email.
Where I use margin
I do not use margins, but if you do use them in your emails please let me know!
The email development process is an ever-evolving beast: if we don't review what we do and why we do it, we run the risk of our process becoming archaic. When I started developing emails, I only used empty cells to control spacing. I did this simply because I didn't realise there were better methods. How do you control spacing? Do you use a mashup of methods or do you stick specifically to one method?