Revisiting the email rendering quirks of Office 365/OWA

Friday November 14th 2014 at 8:49 PM

Recently Microsoft have made an update to its webmail offering Office 365 in terms of how it renders emails. As reported by Nicholas Carter on the Litmus Community many of the previously known Office 365 quirks are no longer happening. Has Microsoft listened to the community on this one and changed its ways? Find out more in my analysis of what’s different under the hood of the Outlook Web App since the changes.

The quirks have left the building

You may have already read my previous article on the many quirks of Office 365/OWA for email designers, now I’m going to reverse it and show what quirks are no longer happening. Here’s the summary of the changes and what’s been fixed.

CSS in head appears to render more reliably, your CSS styling can now be found in a style tag right before your email template body.
ID and class references on elements are no longer stripped. They do however have x_ prepended before the original name. This applies to your CSS in the head as well, along with the addition of a selector
text-decoration:none; is now supported on anchors! (Give someone at Microsoft a medal)
Adding a within an anchor to gain control over its colour is no longer required
Most inline styling on elements is no longer stripped
Images no longer require additional defensive coding measures to fix gaps
OWA no longer adds in deprecated tags like in replacement of CSS styling/font properties. Your CSS properties are parsed directly, without adding additional elements.
text-transform is now supported
text-align justification doesn’t appear to be an issue any more
line-height is now respected and is a lot more consistent
Minimum table cell height is no longer forced at 20px
Image backgrounds now appear to render
OWA generally appears to have a more solid CSS2 support level

That’s quite a list of changes right? Initial analysis of the pre-processor now shows OWA is a lot more relaxed and is allowing much more through than it did before. Have Microsoft been listening to feedback? Looks like it! I’ll go through some the key changes in more detail below.

Under the hood

With all this excitement its important to note that OWA is still very much modifying your email template, but with more relaxed rules, here’s an example of the wrapper that OWA works with now:

<div id="Item.MessagePartBody" role="region" autoid="_rp_K" class="_rp_M3"> 
    <div tabindex="0" role="button" id="Item.MessageUniqueBody" class="_rp_N3 ms-font-weight-regular ms-font-color-neutralDark rpHighlightAllClass rpHighlightBodyClass">
        <!-- The 95c6 portion tends to change to a different 4 character sequence frequently for each mail item -->
        <div class="rps_95c6">
            <style type="text/css">
                /* Your CSS head styles are put here */
            </style>
            <div>
                <div>
                    <!-- Your email template (content after the body tag) will be here -->
                </div>
           </div>
       </div>
    </div>
</div>

This is a little different from the previous wrapper used, it seems to be impossible to actually modify any portion of wrapper itself. The main reasons for this are the use of fairly illegal CSS ID/class naming conventions and because all your CSS rules get modified with slightly different names, meaning targeting such ID/class names is made redundant. See more on this below.

CSS in the head

Previously the CSS in the head of your email template was no where to be found in the source code of OWA, now however a style block is placed just before the beginning of your email template where you can find all your CSS rules albeit with two additional changes.

The rps_xxxx (seemingly random 4 character sequence) class is prepended to the beginning of each CSS rule
x_ is prepended to your ID/Class name on any element that has an ID or class.

A real code example would be:

#outlook a { padding: 0; } /* Before pre-processing */
.rps_c64e #x_outlook a { padding: 0; } /* After pre-processing in OWA */

This example is generic boilerplate code, and not related to OWA itself.

In terms of rendering CSS in the head, rules that target elements within your own email template do indeed appear to be respected. Likewise, general selectors such as table, td, img etc now work more reliably. Generally there is a more consistent behaviour in CSS rendering, whereas before it was rather random, if it even worked at all.

No CSS3 support

OWA doesn’t support any CSS3 still. That’s everything from media queries to any CSS3 specific properties. Media queries are stripped, so are any CSS3 properties, even specific vendor prefixes i.e. -webkit are stripped as well. While we can’t have everything, CSS3 support would be nice to see in the future!

No more HTML 4.01 tags

Previously the pre-processor of Office 365 would take your inline styling, remove some of it and add the parts it removed back in as additional HTML elements like , which while technically legal under the HTML5 specification, have had there purpose redefined since in the HTML 4.01 days. That said, they really shouldn’t be used much these days in the place of CSS properties, the HTML5 specification goes as far to suggest only last resort usage now in some cases.

This behaviour caused some very strange results with layouts. Here’s an example of some of the previous conversions which now no longer occur.

font-weight:bold; /* Converted to <b> */
text-decoration:none; /* Converted to <u> */
font-family /* Converted to <font> */
font-size /* Converted to size attribute on <font> tag and an additional <span> with original value set */

Most inline styling is now kept in tact, meaning you no longer have deal with trying to fix these issues because of these previous modifications.

Microsoft’s comments on the changes

I couldn’t find any specific notes on the rendering changes made to OWA, but the official Office 365 twitter, directed me to couple of entries from the Office 365 blog:

The first article isn’t actually related to OWA as in the webmail client, Microsoft recently released the upcoming version of Outlook for Mac early to Office 365 subscribers which allows syncing of Office 365 mail accounts along with various interface and settings modifications. This however is the full desktop client and not the Outlook Web App. (I’ll be doing another article on it later on).

The second article hints at this being more likely related to the rendering changes, however the article doesn’t mention them directly. Looks like Microsoft have released some updates to the interface and various features, while quietly changing the under the hood stuff. Well, I guess it makes it more fun finding out what’s different!

My thoughts on the changes

This has to be taken as a major step forward for Office 365/OWA, before we were dealing with standards similar to 1999, while a common trend with some email clients, there’s really no excuse for that for a web application such as OWA in today’s web where HTML5 reigns as a leading standard for web apps.

My guess is Microsoft may have quickly realised with OWA being in the past and previously using HTML 4.01 specification type rendering similar to the Word rendering engine of Outlook, would quickly become a problem in a modern world of email. Whatever the motives for change, its good that its happened!

So Microsoft, I approve of all the changes you’ve made, dare I say so does every email developer out there, and I hope more changes are to come! Here’s to a better email experience for Office 365 users!