blog @ pebbl

Have you every tried building a pixel perfect HTML email that works across a range of destination user-agents?

If the answer is yes then you'll know just how frustrating it can be - especially when you include the likes of Lotus Notes (6.5.4) and Outlook 2007/2010. If no, then it's probably only a matter of time, but I wish you luck in avoiding the problem... :)

Now usually - at my company - we stick to a rather rigid design ethic in order to minimize the problems we'll undoubtedly encounter when trying to build complex layouts for these archaic systems. But the other day we had a request from a Designer who wanted to create a layout that would work across all the usual agents we support (which already includes mobile devices) - but he also wanted the layout to keep it's readability on mobile devices without the need for zooming.

Obviously this is achievable, but it's only achievable using a collapsible template (something we usually employ for websites) and then only using quite modern (but degradable) standards. This causes two problems for email:

1. Email is anything but modern - most popular user-agents are at least 5 years old now (if not more).
2. Pretty much the only way to achieve a pixel perfect design in an email is to use tables - and tables are anything but "collapsible" or "degradable".

If at first...

Undeterred by the possible problems, we set about testing different ideas, and just experimenting with the different user-agents at our disposal. Initially everything was far too easy, we almost "seemed" to have a layout that worked in the first 30 minutes, using only the old HTML Table attribute "align" and using separate tables like "cells".

The following example shows two separate tables aligned using align="left"

Now the same code, but forced to wrap at 200px across, as you can see the layout collapses to the parent's width - which is exactly what we needed

So the above handled the collapsing behaviour we needed, but we also required the ability to create "rows" from these left aligned tables. If we just put a whole load of left aligned tables together, they would all wrap along side each other, not really creating the most typical of email layouts... :) So the most obvious way of achieving this was to do what we would normally do in a HTML Email... wrap the aligned tables with another table.

The following shows aligned left tables that would all float in a line, if it weren't for the outer wrapping tables acting as the "row" part of our structure (creating a 2x2 grid).

The above all seemed to work perfectly - mainly in Mac Mail, Win/Mac Thunderbird, Internet Explorer, FireFox, Opera, Chrome and Safari and even Entourage (these being the quickest and easiest to test in). But then, as usual, the respective rugs were pulled out from underneath ourselves once we tested the layout in Outlook 2007.

... you don't succeed?

Whoever thought it would be a good idea to use the Microsoft Word WYSIWYG HTML Engine to render HTML Emails in Outlook 2007 and 2010, must have been mad, lazy, lost or ever-so-slightly confused (delete as appropriate). It causes no end of rendering problems for developers, usually with random and inexplicable sizing calculations or padding problems.

Anyway - complaining aside - it took a little while to work out but it seemed there were a few issues befalling the layout in Outlook:

1. Outlook 2007 automatically shrunk any table with no width set to the smallest width it could have. This obviously affected our outer tables (our "rows") as these only work in a collapsible design if we don't specify a width. This idea had worked in everything save for OL2007 which just ended up auto-collapsing our structure to it's minimum width (rather useless).
2. Our aligned tables did line up as we'd hoped, but there seemed to be inexplicable horizontal spacing (what a surprise!) of about 10px between each table - pretty much useless for a pixel perfect design.
3. There also seemed to be about 10px of vertical space between each group of aligned tables (our "rows").

So after the usual trial and erroring we managed to solve the above problems (almost).

1. Rather than relying on outer tables to create our "rows" we had to remove any non-dimensioned tables. Instead we used a more web page based approach by using a page break with clearing set to "all" (the value of "both" failed to work in OL2007). This introduced another problem, yet more vertical space between each "row". This was fixed by wrapping the <br clear="all"> tag with a <font> tag with it's size and line-height all set to 0.