Outlook and breaks in a very long email.

A good old fashioned TMTC bug, that's what I was missing! Recently, while integrating a HTML campaign, I encountered a recurring problem on my email preview tests on the Emailonacid platform. On Outlook 2007 and Outlook 2010, a huge lag appeared in my clippings...

Well, the rendering problems on Outlook 2007 and 2010, so far, nothing surprising. But I had only encountered this problem once (then very quickly solved by redrawing my table, but without really looking for the origin of the problem and its solution). This time, I needed to understand!

The first step is to debug the email integration.

Maybe a badly closed tag? A duplicate attribute that could "blow up the code"? A problem in my CSS hacks at the beginning of the integration? However, this method is not necessarily productive in this case: Indeed, by deleting this or that module, the problem no longer appears. So you say to yourself: "ok, if I delete this module, the problem doesn't appear anymore. So, the problem comes from this module!" And here we go for half a day of debugging in the wind... I took a lot of money... It's Gregory Van Gilsen, from the Badsender team, who told me the solution (what a swag this Greg!)

Because the problem does not come (really) from a module in particular but well... From emailing in general and the way to integrate! The solution came from a article written in 2011 by Emailonacid (themselves! :D). So the problem is not new (and neither is its solution). However, very few bloggers or email marketing professionals talk about this subject (and especially in French). So I decided to expose it to you in the language of Molière.

Why are there breaks in Outlook depending on the height of the email?

Outlook 2007 and 2010 use the Microsoft Word rendering engine to display an email. So far, nothing new. However, you should know that Microsoft Word offers different display modes: Reading mode, Page and Web. Outlook uses the "Web" view: it is a kind of WYSIWYG editor that issues its own HTML code. Within this mode there are "text limits". Specifically, if you have a <table> height above a certain value (the text limit), a <br> will be inserted and your <table> will break into several tables, creating breaks within your content. Attention, understand well! We have not specified a fixed height to our <table>. It is the height that its content imposes.
The value was given by Emailonacid at the time: it corresponded to 23.7 inches, or about 1790 pixels. And as we often say, a picture is worth a thousand words.

So, here is an example of a quickly designed email. Let's go for the Emailonacid tests, it's going to be skate, brunch and confetti! Don't take into account neither its graphics nor its content, it is fake and generated for the example. Anyway, this is not our focus. So here is a screenshot of the Apple Mail 8 rendering.

Need help?

Reading content isn't everything. The best way is to talk to us.


breaks on outlook email

So everything is ok: no breakage, everything appears correctly and as expected on the mockup. Here is now a capture of the rendering on Outlook 2007 (it is identical for Outlook 2010).

Rendering bugs on Outlook

The problem is clear, but let's point it out anyway.

detail breakage email outlook

Huge breaks appear and shift the whole of my cells. To better understand, here is a diagram of the cut.

Outlook email clipping

This may seem like a strange cutout, but I have to go through this if I want to be able to assign a different link to each visual. But, by framing each picture in my integration with a border of 5px I am even more aware of these integration jumps. You will find them marked with red arrows.

zoom on email breaks

Many comments were left on the page dedicated to the bug on Emailonacid. A solution then evoked at the time in the comments of the Emailonacid topic was to add a conditional comment between the two tables side by side, and thus to separate them in this way:

<!--[if gte mso 9]>
</td>
<td valign="top">
<![endif]-->

However, this fix doesn't seem to work anymore (at least not in our example and in our tests). Other workarounds had also been mentioned but, in my opinion, the simplest solution is to "separate", to cut your painting too big. Then create a new table in which you will place the rest of your email. Thus, the height of the table does not exceed 1790 pixels high, and the breaks do not appear anymore on Outlook 2007 or 2010. Izi!

Share
The author

2 réponses

  1. Indeed, it is necessary to create differentiated tables to avoid that a table reaches the fateful size...
    The word renderer on an email client does a lot of damage 😉

Laisser un commentaire

Your email address will not be published. Les champs obligatoires sont indiqués avec *