Outlook.com Alters Styles of Elements Next to Checkboxes
If there’s one thing you can count on in email, its that Outlook and Gmail will introduce quirks that frustrate email developers who are trying to innovate in email. Sometime over the past two weeks the new Outlook.com (including Office 365 Webmail) started introducing side effects to their processing of checkboxes in email. (Some old Outlook.com accounts are still on the old UI and don’t exhibit this behavior).
Styles of elements following checkboxes are either removed or styles of checkboxes are being appended to the adjacent elements.
How Outlook.com Affects Code With Checkboxes
Outlook.com has always stripped checkboxes and form elements. What is new is that Outlook.com now inexplicably alters styles of elements following checkbox and radio elements.
Note the following code:
|
1 2 |
<input type=checkbox style="display:none !important;"> <div style="width:400px;">CONTENT</div> |
In Outlook.com, the checkbox gets stripped and its style gets appended to the adjacent div.
|
1 |
<div style="display:none !important; width:400px;">CONTENT</div> |
As you can see this results in the adjacent element being hidden!
However, if you leave off the final semicolon (;) from the inline style in the checkbox, instead of copying the style to the next element, Outlook merely…. removes the style!
|
1 2 |
<input type=checkbox style="display:none !important"> <div style="width:400px;">CONTENT</div> |
becomes:
|
1 |
<div style>CONTENT</div> |
Now we have the opposite problem. What if we styled the adjacent element to be hidden? By having the style stripped, the element is no longer is hidden.
Its useful to know that if the adjacent element has no inline style, Outlook locates the next element that has an inline style and messes it up.
Handling the Outlook.com Bug
Note: The option you choose may depend on whether your email service provider alters your code (see ESP section below).
Firstly, you may not necessarily need to fix your code to deal with Outlook.com’s “side effects”. If your checkbox code causes the next element to be hidden in Outlook.com… but you have styled that element to be hidden anyways – no problem!
But if Outlook.com’s checkbox quirks are wrecking havoc with your design, here’s how to deal with it.
Option 1: Use a wrapper with a throwaway inline style
- Make sure your inline styles on your checkbox or radio element does not end with a semi-colon.
- Put a throwaway standalone inline style in the element following the checkbox or radio element. If the following element already contains inline styles, place the throwaway inline style on a wrapper div.
Instead of using a random style like padding:0 for my throwaway style I’m going to use a fake vendor prefixed style -outlook-checkbox-fix:1. This makes it obvious why its there.
So your checkbox code after incorporating checkbox hiding methods would look something like:
|
1 2 3 4 5 6 |
<!--[if mso]><!--> <input type="checkbox" style="display:none !important" checked> <!--<![endif]--> <div class="wrapper" style="-outlook-checkbox-fix:1"> CONTENT </div> |
In Outlook.com, the code above would transform into:
|
1 2 3 |
<div class="x_wrapper" style> CONTENT </div> |
Option 2: Override the display property in the next element
Thanks to Jeremy Martinez for providing this tip in the comments below.
- Make sure your inline styles on your checkbox or radio element ends with a semi-colon (Opposite of Option 1).
- Override the display property with a visible property and !important in the next element. ( “display:block!important” for a div or “display:table!important” for a table)
|
1 2 3 4 5 6 |
<!--[if mso]><!--> <input type="checkbox" style="display:none !important;" checked> <!--<![endif]--> <div style="display:block!important"> CONTENT </div> |
In Outlook.com, the code will be changed to:
|
1 2 3 |
<div style="display:none!important; display:block!important"> CONTENT </div> |
As you can see display:block overrides display:none since it comes after it. However this div can not be hidden using the :checked pseudo-class or a media query (you cannot override an inline !important property with a non-inline !important property). If you coded the element so that its visibility is dependent on the state of the checkbox, the solution is to target a child element to show or hide instead.
Email service provider(ESP) quirks
As most of you know, most email service providers alter your code in some way – sometimes drastically. For example, if you’re using Campaign Monitor, the editor ensures that inline styles always end with a a semi-colon. So if you’re using Campaign Monitor, you’re stuck with Option 2. If your ESP does the opposite, then Option 1 is your only choice.
The way you can figure it out is to send both Option 1 and 2 as a test and see which content blocks are visible in Outlook.com.
Other Outlook.com Quirks
The above bug is particularly gnarly if you’re experimenting with interactive email, so I hope you find the fix above helpful.
However Outlook.com has other choice quirks as well and Rémi Parmentier has cataloged a few of them.
FreshInbox Examples
The examples in this blog has been modified to take into account this Outlook.com bug. However if you come across any issues with the examples with Outlook.com, let me know!
I actually came across this bug on March 15 of this year (I commented it in my template) but never got around to writing about it.
Since the checkbox styles would prepend the styles of the next sibling, I simply overwrote those styles with defaults.
My hacked markup now looks like this:
<input style="display: none!important; max-height: 0; visibility: hidden;" type="checkbox"><table style="display: table!important; visibility: visible; ...{other styles}">
Apparently, I didn’t need to default max-height on the table element – I guess it only applies to block level elements.
This is great Jerry, thanks! I quite like this over an empty element (when dealing with ESPs that add the semi colon at the end) as it doesn’t require an empty element.
Thanks for highlighting and providing a write up on the fix for this Justin. Feels like we’re dodging bullets with these email clients sometimes.
Hmmm… I tried the fix with my carousel code, and it didn’t work. When I tried using the exact example fix above, “CONTENT” is still being hidden in Outlook.com. Maybe something has changed again?
Quick fix right now is just an empty element (like a div) before the div or element with the content, so that it doesn’t get hidden by the display none on the checkbox. Definitely seems like Outlook is putting the inline style of the checkbox on the next element with existing inline style, instead of just removing the (throwaway) inline style, whether there is a semi colon at the end or not on the inline style of the checkbox.
Blame it on the ESP. ;)
Thanks for the help Justin!!
Is there an advantage to using
checkedoverchecked ="checked"in kinetic emails? Or do both behave equally well?From my tests checked works in all the clients that support interactivity so that’s what I went with :)
Hello I have a bug on Outlook365 app, I can see the three images underneath each other while on desktop is working. I tried to fix it but with no result.