Fixing bugs with Outlook specific CSS
Outlook 2007.
Oh boy.
This month marks 10 years since then-CEO Steve Ballmer announced the 2007 version of the Microsoft Office suite. To this day, its email client still sends shivers down the spines of email developers (developers developers…) around the world.
Whereas previous Outlook versions rendered emails with the rather fiddly Internet Explorer engine, Outlook 2007 took fiddly to new levels as the first version to be based on the Word rendering engine. Because Word is a word processor intended for the print medium and not for the web, the switch caused a significant downgrade of Outlook’s HTML and CSS support.
These problems show no signs of stopping as Word is still used as the rendering engine as of the latest Outlook 2016 for Windows.
To help cope, I wanted to share some techniques I use to code CSS that’s targeted only at Outlook, as well as a few examples of when this is useful.
Conditional comments
Thankfully, when Outlook 2007 came out, the Office team took a cue from Internet Explorer and implemented support for conditional comments, as James Edwards discovered and shared in a Sitepoint article.
Conditional comments allow us to add bits of HTML that are only read by the Word-based versions of Outlook.
Conditional stylesheet
The most common way to code Outlook targeted CSS is by placing an embedded stylesheet inside a conditional comment.
<!--[if mso]>
<style type="text/css">
ul {
margin: 0 0 0 24px !important;
}
</style>
<![endif]-->Note the !important declaration which is needed to override inline styles.
The stylesheet will be parsed by the Word-based versions of Outlook. To other rendering engines, the whole block of code will look like an HTML comment they should ignore.
Although I’ve never needed to, you can get more specific with conditional comments that target specific versions of Outlook. Should you need to, here are the mso version numbers that correspond to each Word-based Outlook version.
<!--[if mso 12]>Outlook 2007<![endif]-->
<!--[if mso 14]>Outlook 2010<![endif]-->
<!--[if mso 15]>Outlook 2013<![endif]-->
<!--[if mso 16]>Outlook 2016<![endif]-->Conditional classes
Paul Irish came up with the clever concept of using conditional comments to add different classes to the <html> element when viewed in Internet Explorer.
You may have seen some variation of this in the source code of a web page.
<!--[if IE]><html class="ie"><![endif]-->
<!--[if !IE]><!--><html><!--<![endif]-->The .ie class (or a version specific class) can then be used to prefix a CSS selector in your main stylesheet. The result is a rule that will only be matched in Internet Explorer.
<style type="text/css">
.ie p {
font-size: 18px !important;
}
</style>This exact code actually works in the older versions of Outlook that were based on Internet Explorer. These clients would render the email with whatever version of Internet Explorer was installed on the computer, so you could target specific Internet Explorer version, but not specific Outlook versions like 2000 or 2002.
This approach can be used to work around the lack of media query support in old Internet Explorer versions when coding mobile-first emails. Simply repeat the desktop styles outside of the media query, and give each selector an .ie prefix.
<style type="text/css">
.layout {
width: 320px;
}
@media (min-width: 620px) {
.layout {
width: 600px !important;
}
}
.ie .layout {
width: 600px !important;
}
</style>
The conditional class technique can also be applied in Outlook 2007 and up. These versions don’t support class names on the <html> element, so to get it working, place the conditional comments around the <body> element instead to apply the .mso class.
<!--[if mso]><body class="mso"><![endif]-->
<!--[if !mso]><!--><body><!--<![endif]-->We can then use .mso prefixed selectors to apply CSS specifically for Word-based Outlook.
This has become my preferred fix for Outlook’s Times New Roman issue.
<style type="text/css">
h1 {
font-family: Telefon, sans-serif;
}
.mso h1 {
font-family: sans-serif !important;
}
</style>Faced with an unrecognized font name, Outlook has a tendency to ignore the entire font-family value, including fallbacks, and use Times New Roman instead.
But by using an .mso prefixed selector, we can override the font-family to an Outlook safe choice like the generic sans-serif family, without affecting other email clients.
When to use
Conditional stylesheets are great if you’re hand coding an email template and you need to apply one or more Outlook specific styles throughout the email. This technique is also less likely to interfere with inliners or other parsing steps your template might encounter along the way.
If your workflow involves a pre-processor that necessitates external stylesheet files, then conditional classes can enable Outlook targeting without placing the CSS itself inside conditional comments.
Proprietary Microsoft CSS properties
In order to maintain support for both HTML documents and various Office specific functionality, Word generates markup with a mix of standard CSS and its own Office specific properties. Their HTML and XML Reference lists the supported properties, but the actual documentation of the proprietary properties is sparse.
The Microsoft Office specific properties are mostly mso- prefixed, and the ones useful in emails can be divided into two main groups.
Office alternative properties
Most of the properties that start with an mso- prefix and end with an -alt postfix are direct alternatives to a standard CSS property. For example, the HTML and XML Reference vaguely explains how the mso-padding-alt property is used:
Padding is stored in the mso-padding-alt attribute if the normal HTML padding attribute does not apply.
While it’s not exactly clear when the standard padding property does and doesn’t apply in Microsoft’s view, we email developers only really need to concern ourselves with how the mso-padding-alt property is interpreted when it does exist. Any time an element is styled with both padding and mso-padding-alt, the mso-padding-alt value takes precedence in Outlook, regardless of which order they’re in.
A padding value with an !important declaration does override mso-padding-alt, but because Outlook ignores inline styles with !important declarations, this only applies when overriding the padding from a stylesheet.
One use for Office alternative properties is coding bulletproof buttons without a VML version.
<a href="http://test.com/"
style="background-color: #7fc549;
background-image: linear-gradient(to top, #56ab2f, #a8e063);
border: 1px solid #4e9a2a;
border-radius: 3px;
color: #ffffff;
display: inline-block;
font-family: sans-serif;
font-weight: bold;
mso-border-alt: 8px solid #7fc549;
mso-padding-alt: 0;
padding: 8px 16px;
text-decoration: none;">All Buttoned Up</a>Let’s break down what’s happening here.
In most email clients, this code renders as a link with a background color, a thin border, and padding. The more modern clients will even render a CSS gradient and some nice rounded corners.
Outlook however, doesn’t even properly support padding on links.
If a link has padding only, it renders unpadded, but if it has both a border and padding, the it renders without a background color on the padding.
So to prevent Outlook from rendering an inflated or deflated button, we apply a border of the same color as the fallback background color, to act as faux padding.
The mso-border-alt value of 8px (the maximum border width in Outlook) overrides the border of 1px. And to avoid the transparent padding issue, we override the padding with an mso-padding-alt value of 0.
All of this without affecting any other email clients than the Word-based versions of Outlook.
Hat tip to Joshua Hughes at FreeAgent who originally showed me his faux padding technique that inspired this version.
Office only properties
Then there are the mso- prefixed properties that don’t correspond to a CSS equivalent, but to an Office feature. Many of these have no effect on Outlook, whereas others have almost too much of an effect.
Almost.
There are too many mso- properties to cover here, and many I have yet to even test. But I wanted to share a few that I’ve found uses for in email.
mso-hide
If you have elements you want to completely hide from Outlook readers, the mso-hide: all; property is an easy way to do so. Be aware though, that this magic spell runs out once an email is forwarded in Outlook.
mso-line-height-rule
Many email developers will be familiar with this one. By default, Outlook will treat your line-height value as a minimum, and often increase it to its liking. To disable this behavior, add mso-line-height-rule: exactly; and Outlook will start to treat your line-height value as an exact value instead.
If you want this behavior for most of your email, you can simply apply mso-line-height-rule: exactly; at the <body> level, instead of repeating it throughout the email code. One drawback is that this property can make Outlook crop images by the line height. If a 200px tall image is placed in element with aline-height is 20px, and mso-line-height-rule: exactly; is in effect, Outlook will only show the bottom 20px of the image.
The solution is to revert mso-line-height-rule back to the default value at-least on any elements where it’s causing an issue.
mso-text-raise
Unlike rendering engines intended for the web, Word renders text that sits firmly on the baseline. This discrepancy between Outlook and other email clients is generally not noticeable, but in designs that requires precise vertical alignment, mso-text-raise gives you full control.
For example, to vertically center the text within the line-height, set mso-text-raise to the difference between the font-size and the line-height, divided by two.
<p
style="font-size: 14px;
line-height: 22px;
mso-line-height-rule: exactly;
mso-text-raise: 4px;">
I’m raised off one rule, never get caught slippin’
</p>You can use negative mso-text-raise values too. If your line-height is less than your font-size, a negative mso-text-raise can prevent Outlook from cropping the text.
<p
style="font-size: 30px;
line-height: 22px;
mso-line-height-rule: exactly;
mso-text-raise: -4px;">
CAN’T CROP<br>WON’T CROP
</p>
mso-effects-shadow
This isn’t a direct equivalent of the CSS3 property text-shadow, but a clunkier Office alternative that requires at least five separate properties, for a text shadow that only works in Outlook 2010 and up.
<h1
style="mso-effects-shadow-color: #000000;
mso-effects-shadow-alpha: 30%;
mso-effects-shadow-dpiradius: 4.0pt;
mso-effects-shadow-dpidistance: 3.0pt;
mso-effects-shadow-angledirection: 2700000;
mso-effects-shadow-pctsx: 100%;
mso-effects-shadow-pctsy: 100%;">
MSO Effects Shadow
</h1>
The mso-effects-shadow-alpha (shadow opacity) and mso-effects-shadow-dpiradius (shadow blur) properties are optional. Instead of an x and y offset of the shadow, Outlook’s approach uses a combination of mso-effects-shadow-dpidistance (shadow distance) and mso-effects-shadow-angledirection (shadow angle) to position the shadow. The mso-effects-shadow-pctsx and mso-effects-shadow-pctsy properties let you scale the shadow.
When to use
The convenient thing about mso- prefixed properties is that they let you code self-contained hacks that you can save as snippets and drop into any template, without touching the stylesheet. Assuming your ESP doesn’t strip out unrecognized properties, this approach is also the least likely to cause any issues with inliners or the likes.
The main limitation is that there are only so many useful mso- prefixed properties available.
In closing
Those are the approaches I use to code CSS that targets Outlook only. As with all email hacks, neither one is a universal fix, but hopefully one of them will help the next time Outlook is giving you a hard time.
Are there any I’ve missed? Leave a comment or find me on Twitter.
