Today I learned about mso-generic-font-family…

And solved a twelve years old Outlook mystery along the way.

Rémi Parmentier
emails by HTeuMeuLeu
4 min readJul 17, 2019

--

This morning I was doing some tests in Outlook on supported styles for HTML lists. And my focus quickly diverged to something completely unrelated. Using What does it paste for the first time to get the code generated by Outlook and its Word powered rendering engine, the <head> of the code contained the following:

@font-face? In Outlook? How can that be?

If you’re familiar with web fonts in emails, you know there’s a notorious bug in the Outlooks (2007, 2010, 2013 and 2016) on Windows. Whenever you would import a web font using a @font-face declaration, Outlook would (as one can expect) disregard it. But Outlook would also disregard the font stack declared in your styles, forcing all texts using that web font to Times New Roman. Take the following example:

Outlook would irremediably set that text in Times New Roman, ignoring the sans-serif fallback defined in the font-family property.

Tests screenshots from Email on Acid showing the text set in Times New Roman in Outlook 2016.

A lot of solutions surfaced through the years to avoid this bug, from using !important inline to setting your web font inside a media query. But my favorite has always been to hide the web font inclusion from Outlook using a conditional comment like in the following example.

I always felt that this Outlook behavior was very weird, even by Outlook standards. But that solution worked well enough for me that I never bothered digging any further. Plus, that bug was fixed in the latest Outlook 2019 release, so that case was closed for me. Or so I thought.

When I saw that @font-face declaration added by Outlook this morning, I knew there was something more to it. The following line especially piqued my interest:

I had never ever heard of that property. But that name really sounds like it could play a role in Outlook’s fallback behavior for web fonts.

So I took my first test example, declared my web font in an embedded style tag, and added that mso-generic-font-family property.

And voilà!

Tests screenshots from Email on Acid showing the text set in Arial in Outlook 2016.

The mso-generic-font-family property accepts the following values:

  • decorative
  • modern
  • roman (akin to serif)
  • script
  • swiss (akin to sans-serif)
  • auto (defined to roman by default)

This explains it all. Outlook does support @font-face declarations (but doesn’t load distant fonts). Because Outlook can’t display that font, it falls back to its expected mso-generic-font-family value. And because it’s not defined, it falls back to its auto value, matching the roman font family, thus falling back to Times New Roman.

Case solved.

Digging a little bit further through codes generated by Outlook and Microsoft’s Office HTML reference, I also stumbled on a property named mso-font-alt. This property allows for even more fine tuning for web fonts fallback in Outlook as it can accept another font name. So if we add the following lines to our @font-face declaration, Outlook will first try to apply the font named in the mso-font-alt property (if it’s installed on the machine) and apply the family defined in mso-generic-font-family otherwise.

I hope you enjoyed this read as much as I enjoyed doing this research. I’m now wondering if there’s more to @font-face in Outlook than this. Could there be a way to actually get distant fonts loaded in Outlook? Let me know if you know or find out anything about this.

Want to learn more about emails coding guidelines? I’m hosting a webinar on Smashing Magazine next tuesday (July 23rd at 16:00 GMT).

--

--