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

Tuesday July 22nd 2014 at 1:39 PM

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 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 , and

Office 365 decides to add in several elements that weren’t there in the beginning including font, span and even an old school 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 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 tag is what helps us out here, but interestingly, the is only added in when text-decoration:none; is present on the anchor, without it the 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