Breaks under the images on Outlook.com / Office365?

Hello, little nails! I'm back to tell you about a technical point: the breaks under the images on Outlook! And yeah, I haven't published an article for a while, but that didn't stop me from thinking about you, you know! And today, I'm going to tell you a story... The story of the big bad Microsoft... That alone is chilling...

I recently encountered a "small" difficulty that has been recurring in my tests EmailonAcid. This rendering problem had never appeared before, but emerged, from memory, last week (around March 20, 2017... It must have been 3:11pm...). During my email preview tests, I observed some breaks, slight white lines on Outlook.com and Office 365 appearing under my images. Of course, as you can imagine, I had already correctly filled in my display:inline-block to each of my images. But nothing happened. I specify that these breaks appeared only on my EmailonAcid tests, but not on my real tests. I mention this because it will be important in the rest of this article. (Teasing !!!! I'm good at suspense, I'm sure I could have at least written an S.A.S. I would have called it "Vengeance Outlook" or something like that...)

breaks under outlook images

Here's a little example screenshot to show you! I even put some background colors that sting to my cells so that we can see the breaks!

As I was saying, it was 3:11 pm, the time of the petty digestion, where my eyes sometimes struggle despite listening to the last album, however energetic, of Olafur Arnalds to keep me awake... After trying multiple "Reprocess" on EmailonAcid thinking that the error came from the screenshot of the platform (the easy way out, you know!)I decided to test my code on Litmus instant email preview. Same observation. What could I have done in my HTML code to make this happen? I always do it the same way though, and I rarely change my habits (a bit like Ted Bundy). I then test small fixes, and realize that a style=«font-size:0px ; solves the problem. Coooool! but by the way... why?

I take the bull by the horns and decide to ask the question to the Litmus Community.

A community of #emailgeek as passionate as we are, ready to do anything to find solutions, test, discuss, help ... In short, a community as we like them ... I let you appreciate here my pedagogical tone and my perfect English from Google translate. Yes, okay, I posted this under Gregory's account, so you'll think I don't take responsibility for my questions, but no! Not at all! Anyway, I don't care, I have immunity! 😛

Surprisingly, I discovered the very next day that my question had not gone unanswered. It even generated a certain amount of interest (and the creation of articles as at EmailMonks). And it's definitely MONSIEUR Kevin Mandeville who answers me first. According to Kevin, an update has been made to Outlook.com and Office 365 to allow non-clickable images to be (i.e. without hypertext link) to be viewed "within the email as independent elements" (as I understand it...). As a result, each image without a hyperlink is automatically surrounded by a button. In addition, all images, even if they have a hyperlink, are also surrounded by a div style="display :inline-block ;".

Knowing that (we say well done)Kevin then advised me to put a link on all my images to avoid encountering buttonto surround my images with divs with a specific class, and to specify to this class a behavior in display :block. For example:

<div class="owa">
<img src="img.jpg">
</div>

Will therefore become on Office 365 and Outlook.com :

<div class="x_owa">
<div style="display: inline-block;">
<img src="img.jpg">
</div>
</div>

(If you were wondering at the same time why an "x_" is added to the class, go look at this article by Rémi Parmentier on the new Outlook.com)

Need help?

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


We would then only have to target the dives as follows:

.owa div {
display: block !important;
}

I thanked Kevin for his very pertinent answer (this is the least we can do) and I asked if he knew since when Outlook.com and Office 365 had made this update, and why? But unfortunately, no answer (at the same time Kevin does not work at Microsoft). This is where I got an answer from Rémi Parmentierspecifying (and that's what I told you above) that he did not see this problem on his Outlook.com account (in France) and thus raised the question of :

"Perhaps the update was not made for all Outlook.com users? So we would see the problem appear on Litmus or EmailonAcid, but not on our actual tests."

I then received other answers, very pertinent by the way: It is not necessary to put links on all my images, but rather to target in a general way the div and the button in my style at the top of the mail and to specify a display :block !important ; Others specify that the solution does not work completely on Safari, and that it is necessary to add margin:0 !important ; and padding:0 !important ; to div and button.

For my part, adding display:block blindly on all the div seemed a bit risky to me. When you start on fluid email designs (for a responsive display on Gmail app for example)precisely, we use div for some cells that should, in the desktop version, be displayed side by side. In addition, when you use this design method, you fill in (in principle) a font-size :0 to the cell including your div. Therefore, the breaks are not supposed to appear on the images included in my div...

So I think we need to find a fix that doesn't encroach on this type of structure. As such, we could probably stay with a solution with a font-size:0px ; to all cells with images, a solution that seems to solve the problem... Yes, but what about the rendering on our alternative texts? They will become unreadable!

In my opinion, the ideal solution is close to Kevin Mandeville's. You can't target all the div without dissociation (this would seriously harm the construction of a smooth mail for Gmail app). The solution would be to create a fix targeting only the images within certain td concerned by a particular class. And so I come back to Kevin's solution, which I think is the best:

<div class="owa">
<img src="img.jpg">
</div>

Will therefore become on Office 365 and Outlook.com :

<div class="x_owa">
<div style="display: inline-block;">
<img src="img.jpg">
</div>
</div>

All that would be left is to target the dives (and the button) as follows:

.owa div, button {
display: block !important;
/* et j'ajoute les margin et padding à zéro au cas où, pour Safari */
margin:0px !important;
padding:0px !important;
}

Here you go, folks! I think this technical point was worth bringing up, because it's likely to make many people's heads spin! (As a conclusion, there is nothing better...)

Share
The author

7 réponses

  1. I have the feeling that Microsoft, with each software update, does everything it can to piss off the world! I even have the feeling, after years of using their software on a daily basis, that they have a special department for that, whose unavowed goal is to spoil everything they can by never doing what others do and especially never in a simple and logical way.

    In short, yet another process to add to our emailing integrations only for outlook.com (it's not even the same rendering engine as for outlook 2016) and which will only last for a while since I don't see the supreme interest of their image player which will probably disappear as quickly as it appeared.

    Anyway, thanks for the survey, but I don't thank Microsoft on this one (as on so many others).

  2. To whom do you say it my good man! Let's keep in mind that this problem does not appear in France (at least according to the latest tests). It is therefore not necessarily necessary to include this fix in the immediate future, but we must at least know why the external email preview platforms generate this bug!

  3. I confirm that I had the problem yesterday on outlook.com so the bug does exist in France. I was very happy to find this article to understand what was wrong.

  4. Updates go fast 😉 Good for you if this article was useful, I'm glad! Feel free to share in mâsse and don't forget the pancake that fell in the snow before December 31!

  5. Hey, thanks for this additional information! We've been noticing some weird behavior on Outlook in responsive lately, but I hadn't made the connection! Thanks a lot for this warning! So it's clear that it's starting to be complicated... But fluid is working properly on outlook mobile? For the line-height property, well done, we'll test that too on our side as soon as possible for, why not, the subject of a future article! On the other hand for the links I don't understand what you mean?

  6. Thomas,

    Personally I don't use the fluid/hybrid method especially since gmail supports media queries. For the links if you test for example this newsletter kiabi on the outlook app :

    You will see that the color of the links is blue. The reason is that the text color is declared in both the td tag and the a tag

    Jérémie

Laisser un commentaire

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