365 and Word HTML

Starting with Outlook 2007, Outlook uses only the Word engine to display and create HTML-formatted emails. There had been quite some fuss about this before its release and again before the release of Outlook 2010.

So what is this really all about? Well, to put it short; because it breaks some stuff… But really, trust me, it’s not completely a bad thing that it does so.

Update:
This guide has been slightly updated from the original, which was published in September 2007, to also take Outlook 2010, Outlook 2013 and Outlook 2016, Outlook 2019 and Microsoft 365 into account.

Some background first

Now of course the Outlook developers at Microsoft didn’t break it because they like to break things. Well… maybe they do, but not when it comes to Outlook though.

Since the change, Outlook now only has to support 1 email editor (HTML engine) which makes developing a lot easier and you’ll get a much more consistent behavior which increases your email experience.

In previous versions, Outlook displayed the emails with the HTML rendering engine from Internet Explorer and when you had Outlook as the email editor, it used its own (limited) engine to generate it. When you had Word as the email editor it used the Word engine to generate HTML and offered Word composing features.

With Outlook 2007, and continued in all later versions, they decided to get rid of both Word and Outlook as the email editor and replaced it with a single completely new and revamped editor (with Ribbon support!) based on Word.

Why didn’t they choose Internet Explorer or Outlook?

Well, Internet Explorer only displays HTML and the functionality of the Outlook editor was rather limited. Also, in usage, emails are much more treated like documents than like web pages.

So instead of expanding the features of the limited Outlook editor, and basically build another Word, reusing what they had already made sense. The fact that Outlook and Word have the same release and support cycle will make things even less complicated.

This choice has been validated by the fair share of inconsistencies (and bugs) Outlook 2003 had depending on whether you are using it with Internet Explorer 6, 7, 8, 9, 10 or 11.

An additional explanation has also been posted by Microsoft, when the discussion was brought up again shortly before the release of the Public Beta of Outlook 2010, in the blog post; The Power of Word in Outlook (the original article is no longer available so; Thank you Internet Archive!).

Obviously, now that Microsoft Edge has replaced Internet Explorer, the choice to rely on an editor that is part of Office has been validated once again.

So now I have to buy Word as well? Ripoff!

No, you don’t have to buy Word to use Outlook.

When you install Outlook, it will detect if Word is installed as well. If it is not installed, Outlook will install the so called “stub” of Word that Outlook uses to function correctly and display the new editor.

You see? They really gave it some thought and you’ll benefit from it that you won’t lose Word as the email editor if you choose to only upgrade Outlook.

Note:
There are some features which does require you to have the same version of Outlook and Word installed. However, none of these features were available in the classic Outlook editor either. For an overview of unsupported features and a workaround see; Automatic spell check and Autocorrect not working.

What does it break?

The most noticeable features that are broken are;

gif images don’t animate (unless you are using Microsoft 365)
“advanced” css formatting support (which could lead to malformed newsletters)
HTML accessibility support (like for instance for the visually impaired), although much has improved in Outlook 2016, Outlook 2019 and Microsoft 365.

When you create fancy looking newsletters you can get a full overview of the rendering capabilities of Outlook in the Microsoft Docs guide; Word 2007 HTML and CSS Rendering Capabilities in Outlook 2007.

This guide also applies to Outlook 2010, Outlook 2013 and Outlook 2016, Outlook 2019 and Outlook as part of a Microsoft 365 subscription.

Why are not all the HTML and CSS standards supported?

When you’ve gone through the list of what is and what isn’t supported, you’ll find that most of the things that aren’t supported fall within the following 2 categories;

The feature could pose a risk such as;
- a security risk
- a privacy risk
- inject spoofed content
- execute malicious scripts
The feature doesn’t have to do anything with reading mail

Granted, there are several (formatting) standards which would be nice to see supported and wouldn’t pose a security risk but Microsoft has decided against supporting them for now.

These decisions are usually based on their priority; How much demand is there for a feature, how much resources does it take to implement it (and how much does/could it break by doing so), is there an alternative solution already available?

If you’d like to see improvements made to the HTML/CSS support in Outlook, then you can provide feedback or suggest a feature directly from within Outlook via;

File-> Feedback

Who are affected?

In the positive term; Everybody, as you are now presented with a much more secure messaging environment than if all standards were supported.

In the negative term it is much easier to explain when we define the following four groups;

Everyday email user
Marketing people
Spammers
People who require alternative output or accessibility support

Everyday email user

The everyday email user is not affected by this. When you take a look at your emails, you’ll find that they mainly consist out of text without any required formatting.

In most cases you might as well have used Plain Text formatting instead of HTML.

Marketing people

People in marketing are a bit more affected. They will need to look at their current design templates (usually newsletters) and see if they need to make some changes to their designs.

In many cases there is no need to make changes as they’ve already taken into account mail clients that support even less HTML and CSS features than Outlook. Also, many of the newsletters start with a link to read the information on the company’s website which actually is an increased sales opportunity already (free marketing tip from me ).

The sad story is that there isn’t really a standard for mail clients in terms of which HTML and CSS components they should support, like there is for browsers. It basically comes down to the fact that in order to be compatible with the most mail clients, you’re restricted to a limited set of HTML4 tags, should use CSS as little as possible and test, test, test.

Spammers

Spammers; do I even need to explain this one? As they are basically abusing every trick in the book, giving them less to play with is bad news for them but good news for you and me.

People who require alternative output or accessibility support

Which brings us to the last group; People who require alternative output or accessibility support. From my point of view, this group is the most negatively affected of all.

Some of the features required for this are no longer supported or harder to use. This means that accessibility support is now completely up to Windows, Outlook or a 3rd party application and not up to the sender or the mail properties itself.

I know that in Windows 7, and again in Windows 8 and Windows 10, accessibility support has been vastly improved but I’m not sure if this is enough to compensate for the loss. There also have been made great strides in Outlook 2016, Outlook 2019 and Microsoft 365 (where it became an area of focus for quite some time) so being up-to-date will most certainly help your case.

If you are using Windows and Outlook (any version of either) with alternative output or accessibility support and want to share your experiences, feel free to contact me directly.

How to work around this

For the few times that I do get a newsletter that is totally malformed, I open the message in a web browser. There is a native way to open the message in a web browser by opening the message first and choose;

Actions-> View in Browser.

As this was a bit too many clicks for my taste and because some tags are still stripped, I’ve written a macro to directly display the message (without stripping any tags) in a browser of my choice.

You can find the code and the guide on how to implement it here; Open Message in Internet Browser.

Conclusion

Changing the HTML rendering engine from Internet Explorer to Word has been quite a drastic change which affects various people but doesn’t have a great impact on your everyday Outlook use.

In general the change has had a positive effect on future development of Outlook.

The HTML rendering implementation has also been quite stable so if your design worked in Outlook 2007, it will also continue to work in Outlook 2010, Outlook 2013, Outlook 2016, Outlook 2019 and Microsoft 365.

Making your Outlook implementation decision solely based on these few HTML and CSS support limitations would be blowing things out of perspective.