Background images collapse in Outlook Office365 (Windows) until zoom level is changed
Email Client Outlook (Office365 desktop app , latest version 2505)
Operating System Windows 10
Expected Result Background images in email sections should render correctly on initial load without requiring any user interaction.
Actual Result Background images are initially collapsed/not properly rendered. However, when adjusting the zoom level (either increasing or decreasing, even returning to 100%), the background images suddenly render correctly. This suggests the issue might be related to the initial size calculation, and requires a resize trigger to render properly.
Steps to reproduce
- Send an HTML email containing sections with background images to an Office365 account
- Open the email in Windows 10 Office365 Outlook app
- Observe that background images are not rendering correctly
- Change the zoom level (any level)
- Notice that the background images suddenly render correctly
Screenshots
Screenshot 1: Initial render showing collapsed background images
Screenshot 2: After zoom adjustment showing correct rendering
Code sample Example email can be viewed here: https://mjml.io/try-it-live/5K5_i4f5yv
MJML preview can view the complete HTML. If need to view the complete HTML file, you can view the following files example.txt
Additional Notes
- This issue appears to be specific to the Windows 10 Office365 Outlook app
- The problem occurs consistently with background images in email sections
- Any zoom level adjustment (even returning to 100%) triggers correct rendering
- This suggests a potential issue with the initial size calculation or rendering trigger in the Outlook app
Related issue https://github.com/mjmlio/mjml/issues/2955
I can reproduce this (I am on v. 2506) using the supplied test HTML.
And I think it might be related to the dreaded Advanced Typography Feature.
The issue resolves when you disable Advanced Typography (File > Options > Mail > Editor Options > Advanced > Scroll down to Advanced Typography > Untick "Use Advanced Typography")
After re-testing with that disabled, the text always appears below the background image area again.
Hmm 🧐
Later update: None of the code-based fixes for disabling Advanced Typography (like here) have any effect on this unfortunately. The only way to stop it is to manually turn off the settings within Outlook.
In terms of how to solve inside email code, after investigating more this afternoon, I agree with iRyusa's comment at https://github.com/mjmlio/mjml/issues/2955#issuecomment-2960053073 that it seems related to mso-fit-shape-to-text.
When set to false, you can see that bottom of the text match up exactly*.
It does seem like this is how it is being positioned when mso-fit-shape-to-text is set to true except the text is failing to move down from this position.
So if you are able to set a height on your rect then if you set mso-fit-shape-to-text to false (or just remove it, since false is default) then that is one way to get around it.
(*Edited: previous example was mismatched but I forgot I'd been testing line-breaks.)
I'm fairly certain I've encountered this bug years and years ago, before Advanced Typography even came to be. I've unfortunately not been able to fix it and resorted to using overlapping content in VML instead.
Oh, interesting! I felt like I've never seen exactly this situation before, but it may indeed be an old bug.
Curiously the Advanced Typography thing does stop it happening when you turn it off. 🤷
Anyway I'll be interested if anyone else sees their backgrounds behaving any differently all of a sudden. (I'm also making the assumption that the MJML code was functional up until recently but I couldn't know that for sure.)
I was intrigued by this bug, since I haven't encountered it myself. I tested several templates with background images that I have, and everything displays correctly on testi@.
It's worth what it's worth, I'm just putting this out there for information.
I tested the provided code, and indeed, for me, it's mainly buggy on Outlook 2019 (2504) and Outlook 2016 Pro Plus (2504). I have Office 365 (2408), which displays correctly. And on the 365 versions of testi@, it also displays correctly. According to you, it also bugs on the latest version of office.
As we can see on the first and last thumbnails, the text goes under the image, as if it were in absolute position. But basically, Outlook automatically calculates the height of the block, we find, even on the versions which bug a fixed height of 281.9pt in the vml code..
As iRyusa and Nicole suggests, if we remove mso-fit-shape-to-text and specify a hard-coded height, it displays correctly again. That would be the simplest solution.
Otherwise, to try to understand, I proceeded by process of elimination.
1-If we remove the two occurrences of style="line-height:0px;font-size:0px;mso-line-height-rule:exactly;
on lines 93 and 188, we fix the problem in Outlook 2019.
2-If we add a <br/>` between the two main divs (inside conditionnal comments), it also fixes the overlapping problem in Outlook 2016 Pro Plus (2504).
But now, on testi@, the email seems to be cut off after the first line on 365. I don't know if it's a loading problem or not.
I checked the code differences between all these versions and there's nothing obvious. But since my other templates don't display this bug, I think there is something in the code that is causing the display to be buggy on these versions.
What is strange once I have done all that, is to think that an option in Outlook corrects everything in one go..^^
1-If we remove the two occurrences of style="line-height:0px;font-size:0px;mso-line-height-rule:exactly; on lines 93 and 188, we fix the problem in Outlook 2019.
I have tried to delete these two styles, but it doesn't work.
2-If we add a
` between the two main divs (inside conditionnal comments), it also fixes the overlapping problem in Outlook 2016 Pro Plus (2504).
Tried the same, didn't work.
https://github.com/user-attachments/assets/e46fb8fb-ea2d-4a27-aade-fdf7be6029c1
I've noticed another interesting behavior related to this issue. When I first open the email, the background images are indeed collapsed. However, when I double-click to open the email in a new internal window, the collapsed state disappears and the images display normally.
This seems to be another trigger that forces Outlook to properly render the background images, similar to the zoom level change mentioned in the original issue. Both actions (changing zoom or opening in new window) appear to force Outlook to recalculate the layout, resulting in correct rendering.
Throwing a group around the object seems to fix the height.
When using a group, the VML objects inside (such as rect, shape, roundrect) no longer require a width or height as it'll pick it up based on the parent group's setting.
So here's an example:
<v:group coordsize="600,15" coordorigin="0,0" style="width:450pt;height:15pt;"> <v:rect fillcolor="#ff5500" stroke="f" style="display:inline-block;"> <v:textbox style="mso-fit-shape-to-text:t" inset="0,0,0,0">
My content I used within was around 800px tall and appeared correctly in my direct tests.
I think it might be because Outlook doesn't re-compute mso-fit-shape-to-text once the loading is done.
Anyway I'll be interested if anyone else sees their backgrounds behaving any differently all of a sudden. (I'm also making the assumption that the MJML code was functional up until recently but I couldn't know that for sure.)
I'm not super active in MJML, but it was working for a while now yes
I wonder if it has something to do with the padding bug we saw in other issue (when you have more than 1 table inside a VML group, padding left is applied to the right)
I'm confident this was caused by a recent Outlook update within the past couple weeks. I have reoccurring weekly projects for one client that utilizes the fit shape to text option in the same layouts, and it was the most recent ones that started showing the collapsed view for code that had tested fine in prior weeks (and over several months).
Outlook Version 2508 (Build 19127.20314 Click-to-Run) seems to have resolved the issue.