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 <span> within an anchor to gain control over its colour is no longer required

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:

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.

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 <b> <u>, 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.

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!

Someone else reported this happening, I initially didn’t see the problem, but I then noticed on tests emails from Email on Acid that anchors were getting messed with on screenshot previews, essentially the href of the anchor would bleed out as actual text.

When the actual live email campaign ended up in Office 365 inbox however, the problem did not show up.

I initially put it down to perhaps placeholder tags in href tripping up the OWA pre-processor, I haven’t looked into it further.

Litmus just recently added screenshots for Office 365. I found out right away that it doesn’t seem to like a hash (#) used as a placeholder (though something like “#texthere#texthere” seems to be fine). It caused some styling/layout issues for that CTA and the next segment of the email below it (basically looked like all the link styling was removed from the CTA and got mushed into the next segment). Once replaced with a proper URL, it all went back to normal!

The # placeholder was also applied to a title and image in the same segment as the CTA, but they appeared to be unaffected? Hard to tell, but something to watch out for.

Ellen Manuszak

Thanks for this info, Courtney, helped fix the issue for me

Haley

Have you done any testing with conditional comments? The lack of media query support has got me stuck trying to create responsive emails for OWA, and I’m struggling with the “workarounds” I’ve found on other forums.