After seeing some pretty weird results from the Outlook 365 mail box, this article will see what exactly Office 365 (OWA) is doing to email in terms of the output after going through the pre-processor. As a conclusion, the Office 365 OWA app is worse than Outlook 2007 2013 for standards support. Find out about the details about this email client below.
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 wouldnt normally expect. The main reason for this is various elements either get converted or added in where they werent originally, creating much of the strange behaviour documented in this article.
OWA is also removing inline styling on a lot of elements that youd usually think are safe. Well in Office 365 NO ELEMENT IS SAFE! Further bad news, OWA doesnt 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.
Processing Changes
- All CSS in the head is removed
- All CSS classes/IDs are remove from all elements.
- All inline styling is stripped on <a> and <img>
- border:none; wont 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 doesnt 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 doesnt work reliably.
The Framework
Office 365 wraps any email with a couple of divs which do include some classes and IDs, 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>
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 werent 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 youll still have the ugly underlined border.
Note: It also seems that OWA doesnt always honour the colour of white or #ffffff, it sometimes works and sometimes doesnt, 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 center 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 doesnt 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 doesnt 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:
- 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 attribute method is a simpler fix, which does have varying levels of success. If however the align method cant be used for whatever reason or simply doesnt work (some users report it doesnt), you will need to use the div wrapping method.
The logic behind the image within a div method is by wrapping a <div> tag around an image you have simulated display:block; as a div is a block level element. Doing this however has implications for Outlook 2007 2013, so test this fix thoroughly to avoid regression issues. It is unfortunately very easy to fix one problem but break something else in another email client, especially Outlook!
In conclusion, we now have another client to keep in mind when designing.