Office 365 (OWA) and its many, many quirks for email designers

36
Office 365

I decided to purchase a single Office 365 Mailbox recently to see what exactly Office 365 (OWA) is doing to email in terms of the output after going through the pre-processor, after seeing some pretty weird results from inbox inspection test from Office 365. Turns out after looking into things, I’ve come to the conclusion that the Office 365 OWA app is worse than Outlook 2007 – 2013 for standards support. Find out about the quirks with this email client below.

Update 15/10/2014:

An update to Office 365/OWA has meant the quirks documented here no longer occur! You can find my updated article on Office 365 and how it renders email which details what’s changed. This article will be kept for comparison purposes. However, you no longer have use any of the fixes documented here any more!

Pre-processor analysis

After using Firebug to examine the email in the inbox of in the OWA app within Office 365, the short answer to it all is the OWA pre-processor changes A LOT of elements that creates weird glitches that you wouldn’t normally expect. The main reason for this is various elements either get converted or added in where they weren’t originally, creating much of the strange behaviour documented in this article.

OWA is also removing inline styling on a lot of elements that you’d usually think are safe. Well in Office 365 NO ELEMENT IS SAFE! Further bad news, OWA doesn’t support CSS in the head. Making any client specific CSS to ease the pain impossible.

Note: By OWA I am referring to the Outlook Web App which is what Office 365 client is. OWA is also known as Outlook Web Access for other implementations of Exchange Server. There are some differences between the older OWA apps and Office 365.

My findings/observations

Inspired by the findings of Email on Acid, here are my own findings/observations.

  • All CSS in the head is removed See updated note on this below
  • All CSS classes/ID’s are remove from all elements.
  • All inline styling is stripped on <a> and <img>
  • border:none; won’t fix blue borders around images (due to bullet point 3)
  • Lack of text-decoration:none; support on anchors (due to bullet point 3)
  • Using align=”center” on a table cell to centre a nested table doesn’t work.
  • Gaps with images (noticeable when image slicing)
  • Some styling properties placed on elements like <td> tag will be placed upon a font or span tag which OWA will “kindly” add for you.
  • Styling properties like font-weight:bold; will get converted to a <b> tag
  • font-size property gets converted to a font tag with a span placed within the font tag, that has the size of the original font-size property set inline on the span
  • #FFFFFF or the colour white on anchors doesn’t work reliably.

The foundation

Office 365 wraps any email with a couple of divs which do include some classes and ID’s, however due to lack of CSS support in the head, client specific CSS is impossible, which is a shame as Outlook.com and even Outlook allows for conditional hacks.

<div id="Item.MessagePartBody" class="_rp_J3"> 
	<div id="Item.MessageUniqueBody" class="_rp_K3 ms-font-weight-regular ms-font-color-neutralDark rpHighlightAllClass rpHighlightBodyClass">
		<div>
			<div style="width:100%;margin:0;padding:0;">
				<!-- Your completely butchered email code will be here -->
			</div>
		</div>
	</div>
</div>

Embedded CSS in the <head>

Update: 02/09/2014

I’ve discovered that my original note of of all CSS in the head being removed is not entirely accurate. The CSS certainly isn’t present in the source code after analysing the email with firebug but according to the email rendering test below, CSS in head does respond as true meaning the specific CSS class that triggers that specific table cell to change to green was parsed in some way by OWA.

However, CSS in head seems very hit and miss in Office 365. Some selectors don’t respond at all, others respond but only when certain properties are used, and sometimes a combination of properties only works.

Office 365 (OWA) rendering test result

Colours and underlines on links

One of the major issues with OWA is link colours and the ugly underlines. As noted, any inline styling is removed on anchors, making it insanely hard to control a normally simple area. In addition to this some really freaky stuff goes on with a simple table cell holding an <a>, here is an example of a padded button before and after its hit the inbox of Office 365.

Before Office 365 messes with it:

<td align="center" valign="middle" bgcolor="#ec0089" style="padding-top:15px; padding-right:20px; padding-bottom:15px; padding-left:20px; font-family:Helvetica,Arial,sans-serif; color:#ffffff; font-weight:bold; font-size:17px; letter-spacing:-1px; line-height:20px">
	<a href="http://awebsite.com" style="text-decoration:none; color:#ffffff" target="_blank">A button</a>
</td>

And now after Office 365 has messed with it:

<td style="text-align:center;background-color:#EC0089;padding:15px 20px;" align="center" valign="middle">
	<font color="white" face="Helvetica,Arial,sans-serif" size="2">
		<span style="font-size:17px;background-color:#EC0089;">
			<b>
				<a href="http://awebsite.com" target="_blank">A button</a> 
			</b>
		</span>
	</font>
</td>

Why hello there <font>, <span> and <b>

Office 365 decides to add in several elements that weren’t there in the beginning including font, span and even an old school <b> tag, due to the font-weight property. Retro.

The breakdown of the pre-processor modifications appears to be:

  • Font declaration gets placed onto a font tag added within the original table cell, likewise it decides to set a size similar to the original px value provided.
  • A span within the added font tag then adds the font-size set that was present on the table cell originally
  • Using font-weight creates a further <b> tag placed within the created span.

After all of this, the original anchor is present, minus any inline styling, more critically the lack of colour and text-decoration is now a problem.

  • The colour of your link is now at the mercy of the default link colour of the browser you are accessing OWA in.
  • The underline on links will now be present.

You can get around the link colour issue, by wrapping the text content within the anchor in a span tag with a color property:

<a href="http://awebsite.com" style="color:#fffffe">
    <span style="color:#fffffe">A link</span>
</a>

This will stop the colour from being messed with, but you’ll still have the ugly underlined border.

Note: It also seems that OWA doesn’t always honour the colour of white or #ffffff, it sometimes works and sometimes doesn’t, a workaround is to drop the hex value by one place (#fffffe)

Regaining some control over underline colours

One trick I found out recently is being able to regain some control over the underline border colour for certain situations. Using the nested span within anchor trick above, I was able to leverage the OWA pre-processor to my advantage.

Lets start with the anchor and span combo example above:

<a href="http://awebsite.com" style="color:#26B4F0;">
    <span style="color:#26B4F0;">Click here</span>
</a>

Like the example above, this will allow you to set the link colour to what it should be, but underline will remain at the mercy of the default states in the browser. However if you add a text-decoration:none; property to the anchor and then add a text-decoration:underline; to the span, you will be able to have both the link colour and underline the correct colour!

<a href="http://awebsite.com" style="color:#26B4F0; text-decoration:none;">
    <span style="color:#26B4F0; text-decoration:underline;">Click here</span>
</a>

Why this works is ironically because of text-decoration:none; property. The pre-processor is obviously seeking out this CSS property and has some logic to determine what it should do to the rest of the code within the anchor when it sees this CSS property applied. In this case Office 365 turns it into this:

<a href="http://awebsite.com" target="_blank">
    <font color="#26B4F0">
        <u>Click here</u>
    </font>
</a>

The addition of the <u> tag is what helps us out here, but interestingly, the <u> is only added in when text-decoration:none; is present on the anchor, without it the <u> tag is not added and the underline colour remains the browser default. So while text-decoration:none; gets stripped the Office 365 pre-processor is aware of it, and has certain logic to rewrite code.

Using centre aligning on table cells to centre nested tables

My coding style has always been apply a majority of styling to table cells and nest tables rather than style tables themselves as to me it seems safer, however one thing that caught me out is using the table cell align method to centre a nested table doesn’t work with OWA.

For example, this will not work in OWA:

<td align="center" valign="top">
	<table border="0" cellpadding="0" cellspacing="0">
		<tr>
			<td align="left" valign="top">Some content</td>
		</tr>
	</table>
</td>

This however will work in OWA:

<td align="center" valign="top">
	<table border="0" cellpadding="0" cellspacing="0" align="center">
		<tr>
			<td align="left" valign="top">Some content</td>
		</tr>
	</table>
</td>

Blue borders around images

If you use border:none to fix the blue borders issues around images, bad news it doesn’t work here. As noted originally all inline styling is removed from images. However standard attributes remain intact, this means you can pull off the good old border=”0″ fix.

<a href="http://awebsite.com" target="_blank">
    <img src="/path/to/image.jpg" alt="A image" width="200" height="200" border="0" />
</a>

Gaps with images

The image gap issue is caused by the HTML5 doctype, normally you would apply the common display:block; fix to the image to neutralise the gap, however as noted you cannot use this method to fix the problem in Office 365 as all inline styling is stripped on images. Additional work is required.

There are two known alternative methods available to fix this that will work with Office 365:

  • Use the align attribute on images
  • Wrap the image in a div and set a height on the div matching the height of the image

The align method

The align attribute method is a simpler fix, which does have varying levels of success.

<img src="path/to/image.jpg" alt="Image Description" style="display:block;" width="200" height="200" align="left" />

However it doesn’t always work and can actually cause spacing issues for older IE clients.

The defensive div approach

<div style="height:200px;">
    <img src="path/to/image.jpg" alt="Image Description" style="display:block;" width="200" height="200" />
</div>

The logic behind this method is by wrapping a <div> tag around an image you have simulated display:block; as its a block level element. Setting a height inline on the div that matches the image height will remove the gap.

Additionally you can also set font-size:0; on the containing block element that contains the image i.e table cell to reduce gap spacing as well. Sometimes depending on certain CSS properties set, the div wrapping trick won’t fully fix the issue. Particularly the use of line-height on the containing element will often undo the fix.

<td style="font-size:0">
    <div style="height:200px;">
        <img src="path/to/image.jpg" alt="Image Description" style="display:block;" width="200" height="200" />
    </div>
</td>

What actually happens, is the whole div/image gets wrapped in a font tag with the size set as 1 and the gap is neutralised once more.

Overall this method has more success, but it is more involved and adds extra markup. Joy.

Original Email on Acid article for reference

Got anything else to add?

Know any other quirks or fixes for OWA in Office 365? Why not share them in the comments below!

Share This:

  • Awesome post.. thanks for sharing all of your hard work!

    Now I will just go and cry some more about all the ways in which Microsoft ruins our lives.

    • Thanks for commenting!

      I know right, as if Outlook wasn’t a big enough challenge, now we have more Microsoft products to fight with!

      Usage of Office 365 I’d imagine is quite low at this point as its a
      relatively new product, but I’m sure usage figures will increase over
      time.

  • RonaldDijkstra

    Some niceties in this post, thank you.

    Is there a difference between the preview pane and accessing the email itself? Lots of the stuff you describe is already there in older OWA versions. My employer has one subscriber list with 95% OWA users (2010 version). Optimization of the template was horrific. I noticed a big difference between viewing the email in preview and accessing the mail itself, the latter seems not to strip head and other css.

    • I didn’t find any noticeable differences in the preview pane and opening the email in its own window. If its broken in the preview pane, its broken in general.

      The main problem with OWA is it has many different implementations across various versions of Microsoft Exchange Server. For example, its called Outlook Web Access for organisations using their own on premise Exchange Server. Then you have to contend with each different version of Microsoft Exchange, 2003, 2007, 2010 etc. all coming with different versions of OWA.

      There are some similar behaviours in Office 365 OWA and older OWA versions but I guess that logical, because its still at its core the same product, I’m sure however you will agree Office 365 as some unique quirks.

  • Justin Khoo

    James, I’m curious if Office 365 strips other attributes on elements other than class and id’s.

    Gmail does not strip certain attributes such as title and I was able to use that with attribute selectors:

    http://freshinbox.com/blog/interactive-emails-in-gmail-using-css-attribute-selectors/

    • It appears Office 365 do not remove HTML attributes. The border attribute is classic example. I will have to test your idea further as its a good point!

      • Justin Khoo

        Looking forward to see if it will work :)

        • Testing this now currently, with a special rendering test email I’ve cooked up. Initial tests show Office 365 is generally a lot stricter and strips most of the mentioned attributes that Gmail doesn’t in that article. For the select few that do remain in tact however, I think the lack of CSS support for attribute selectors in Office 365 will make this method all but useless. However, here’s a peek at what survives Office 365 pre-processor:

          http://blog.jmwhite.co.uk/wp-content/uploads/2014/08/office-365-attribute-support.jpg

  • Samantha Iodice

    Hi James,
    Did you find any issues with HREFs and link breakage? We’re running into issues in conjunction with Perl scripts for dynamic links.

    • Didn’t see any href attribute breakage during my tests. What issues are you noticing?

      • Samantha Iodice

        A heavily dynamic email, using Perl to pull in the appropriate link per the data file, is breaking and displaying the full link, complete with HREF over the button for which it’s programmed.

        • Are you able to view the email in the Office 365 OWA app to see if the pre-processor has caused syntax issues?

        • Funnily enough I recently came across the problem you are describing, however it appeared on an Inbox Inspection test on Email on Acid, but when I sent it to a live Office 365 mailbox and viewed it in OWA, the problem didn’t occur. Did you see the described behaviour on a screenshot from EOA?

  • j0hn

    Oh my god, why? D’:

  • massachusetts

    Hi, i’m working on responsive html emails and have a problem in office 365. emailonacid tests shows my templates have the same width as the screen/ (but i’ve set max-width to 600px, width: 100%. and i also have a fix for outlook:
    !–[if (gte mso 9)|(IE)]>

    tr>
    td>
    ![endif]–
    maybe you have an idea what causes my problem?

    • Office 365 will not respond TRUE to this conditional comment, or any conditional comments for that matter, and because it doesn’t support max-width it will render the first table that has 100% width set.

      At this time I don’t know of any workaround for it other than defining a fixed width, but that would affect the entire layout and remove the fluid approach that you are using.

  • massachusetts

    thank ypu. maybe you know if office 365 cut/don’t understand !–[if (gte mso 9)|(IE)]

    • I’m afraid it doesn’t. You can’t target Office 365 via any conditional comments.

  • massachusetts

    one more question…
    how to set line-height to my template?

    • I’m investigating line height issues more thoroughly, as this is another issue with Office 365 because it strips out the line-height property entirely. I’ll update the article when I find out more.

      • massachusetts

        i’ve found that it uses normal line-height of parent elements font-size. so i decided to set font-size in every element. but if you set font-size in and in office 365 cuts off them. so i set font-size in every . but it also not an ending solution, because of using elements with different font size in one block (for examle, 13px and 40px) they all take normal line-height from parent element (for example, font-size 13px and normal line-height for it is 19px, so both elements with font-size 13px and 40px takes line-height 19px;)

        • Interesting finds! I’ll be doing some more testing soon and will use your findings. Thanks!

      • massachusetts

        i still have one more question))
        i’ve found that office365 cuts off display: none, and i really don’t know how to fix it(

        • Try using font-size:0; on a block level element

          • massachusetts

            i’ve tried this but it works like hidden not display: none;

          • Try a combination of any of the following.

            display: none;
            font-size: 0;
            max-height: 0;
            line-height: 0;
            padding: 0;
            visibility:hidden;
            overflow:hidden;

      • massachusetts

        i’m still working on html emails coding(, and i still have to support office 365, so…

        office 365 cuts off line-height, example:

        this

        transforms
        into

        You can notice that there is no line-height, so
        it takes “line-height: normal” from
        parent element with font-size

        (NOTE: “normal” is different for different
        fonts; font-sizes ignores for tag table, maybe the reason is that font-size
        transforms into and in tables it
        is impossible because after tag table there is tag tbody in HTML)

        So I set font-size for every element in templates (and trying to use the
        most suitable size to the aimed line-height).

  • The S

    Really late addition that I just found: OWA (2010, at least) changes style=”text-transform: capitalize;” into “text-transform: uppercase;”!

    I defy anyone to explain what purpose is served by this bizarre mangling. I mean, geez, just strip it out, don’t change the (from a marketing perspective) semantics so it looks like we’re YELLING.

    • Interesting find. I remember Office 365 used to strip text-transform entirely, so you’d have to actually write all text as you’d want it in the HTML, I no longer believe this is the case since the October 2014 update. Older versions of OWA are likely to have strange issues, sums up the client as a whole really!

  • Fusty

    Great work, this is so massively frustrating.

    I wish Email client developers (or their bosses) understood the impacts of these decisions. When folks like us who write software that generates emails we have to write so it’ll look acceptable in clients like this. None of the popular email clients behave the same, they all have tons of quirks. Now when another one shows up with a ton of new VERY impactful quirks like Office 365/OWA 2013 compensating becomes difficult.

    Basically what happens is once two clients handle something differently enough that you either A. Stop using that display element entirely or B. find a workaround but this workaround is applied to emails that reach clients not needing the work around. This compounds with each shitty client that is out there until we are left with the most insanely inconsistent and tiny subset of HTML that leaves emails looking like absolute crap.

    I am so sick of this, it is destroying the very idea of sending information via email as I will just end up linking folks out to the web where formatting alone doesn’t take up 95% of my time.

  • Ricson Goo

    Quite old topic but just wan to do a kindly remind, try to avoid use font-size:0 or 0px in an email if you can, because some email spamfilter may think this is a spam email…

    • Indeed. It is a hack after all, they often have side effects! The good news is you don’t have to use it any more, as Office 365 no longer removes display:block; from the image element.

  • Andy

    An easier way to fix the text-decoration:none issue is to convert your links to inline-block using the display property.

  • Ryan

    If you put !important in the header styles, you have much more control.

  • Peter Flynn

    Wonderfully useful, thanks. I just hit a new one: links to PDF documents don’t display as links: instead, the element content is prefixed by the URI in square brackets. Thanks, Microsoft.

  • trizamisu

    In Outlook 365, href=”mailto: subject= body= does not work fully. Outlook will open up an email with the subject correctly populated but the body is empty. Any advice on how to get around this issue?