Community Forum

Over the years we have built up a community of email marketers, coders and designers that live and breathe email.

Use the Email on Acid Forum like your virtual water cooler: Stop by to discuss email code, quirky clients and fixes and post your issues (with an example of the code) for our community to offer its assistance.

TD padding in IE vs all other Browsers


Total Posts:  43
Posted: 15 September 2010 11:25 PM

This issue has come up a few times so I figured I would share it in the forums:

Every HTML element is essentially a box, the width of which is the total of its margin, border, padding and content area. Imagine the following CSS rule:

td {
border1px solid #eee;

This means that each TD is 42px wide in total. This amount is made up of a 30px wide content area, a 5px padding on each side, and 1px border on each side.

In IE however, the border and padding are included in the width of the content, as opposed to added on. Therefore, the total width of the content in IE is only 30px (12px less because of the 5px padding and border on each side).

This works the same way if you had a width attribute of “30” within your TD.

Obviously the way to get around this when designing web pages is to link an additional CSS file for IE only but when designing emailers, it’s not that easy.

The way we see it, you have 2 options, feel free to share your workarounds if you have more:

1.) Use nested tables so that the containing TD has padding but no width and the nested table has a TABLE width and no padding.

2.) Avoid the width attribute/property all together and use clear GIFs inside your TDs. Note: Each GIF must be created using its exact dimensions for Outlook 2007 and 2010 - because it doesn’t always support image width/height attributes.



Total Posts:  11
Posted: 23 November 2010 03:39 PM
[ # 1 ]

You’re referring to the Box Model problem, right?

I’ve never noticed it with tables however. With cellspacing and cellpadding, it hasn’t acted the same way as in padding and margin on a div.

However, since a large target base of ours is in Outlook 2003 with 2010 just around the corner (operating the same as 2007) we run into issues that we have solved this way.

We don’t use css at all. We don’t use spacer gif either, and if we have a nested table, we make sure that nested table doesn’t have a height or width but rather its containing cell, the TD, is defined. This way, the table will reach out as far as it can but w/o predefined widths/heights, we don’t get into trouble of wrong values since the only value being ‘read’ is the main structure cell.

So, it does become a nusiance creating margins with rowspans, but my personal technique has been to avoid rowspans as much as possible as colspans seem to work better in terms of a hornets nest of tables.

Finally, that’s the reason I’ve turned to inputting my code within Photoshop, slicing and exporting and just adding the right doctype because the tables are much easier to create than doing it by hand.


Michelle Klann

Total Posts:  204
Posted: 23 November 2010 09:08 PM
[ # 2 ]

Thanks Thumbslinger for adding your suggestions to this post. 

To throw some more info into the mix - we’ve done some recent research on DOCTYPE and found that it directly impacts the box model padding issues discussed here. 

Interestingly enough, if you use any DOCTYPE other than:
<!DOCTYPE html PUBLIC “-//W3C//DTD HTML 3.2 Final//EN>
IE and all other browsers will render box padding the exact same.

The problem with email clients is that most of them strip out the DOCTYPE entirely which causes the box model issue to become a factor again.

Here is the complete article:
!DOCTYPE - The Black Sheep of HTML Email Design