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:

<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.

<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!

<input type=checkbox style="display:none !important">
<div style="width:400px;">CONTENT</div>

becomes:

<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

1. Make sure your inline styles on your checkbox or radio element does not end with a semi-colon.
   
2. 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:

<!--[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:

<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.

1. Make sure your inline styles on your checkbox or radio element ends with a semi-colon (Opposite of Option 1).
   
2. 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)

<!--[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:

<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!