Outlook renders with Word
A client asked whether the newsletter could look like the site.
Yes, mostly. Then I spent the rest of the call on the mostly.
It’s a completely fair question. Most of the email work here comes to me now. When a redesign launches, an account manager pulls me onto some version of this call.
This client had just watched us rebuild the front of their business. The newsletter that actually goes out to their customers every couple weeks still looked like a stock template with the logo swapped in.
They wanted the same green, the same typeface, and the same row of three cards with a rounded button at the bottom of each one. None of that is exotic and the site does all of it without being asked.
The honest answer takes a while because HTML email isn’t the web with a few things taken away. It’s a separate medium that happens to use similar syntax. Its rendering situation is roughly where the web was in 1997, and there’s no mechanism by which that ever changes.
The call always ends the same way, with a pause and then the client figuring out that I’m not making excuses.
It looks like you’re writing an email
One fact explains most of the rest. Since 2007, Outlook on Windows has laid out HTML email using the Microsoft Word layout engine. I don’t mean a browser engine that Microsoft happened to own. I mean the word processor.
Microsoft did it on purpose, and I think that’s worth knowing before anybody gets indignant about it. They wanted a message composed in Word and a message composed in Outlook to come out the same, and you guarantee that by using one engine for both. As a product decision it’s perfectly coherent.
It also froze the renderer in place. An enormous share of business email passes through something that was never meant to lay out a page.
In that engine float does nothing and neither does max-width. A background image on a div does nothing, padding is ignored on some elements, and margins are a coin flip. Anything you’d reach for to build a layout is missing because a word processor never needed any of it.
That includes the typeface. Outlook won’t load a web font, and if the one you asked for isn’t installed it skips the rest of your font stack and sets the email in Times New Roman. Gmail won’t load one either. So “the same typeface” means Apple Mail and the iPhone, with a carefully chosen fallback everywhere else.
Outlook does have VML, which Microsoft and a few partners submitted to the W3C in 1998. It lost to SVG and lives on inside this one program.
So when you want the client’s rounded button or a section with a background image or the whole nine yards, you write this next to your ordinary markup and wrap it in a conditional comment so nothing else has to look at it.
<!--[if mso]>
<v:roundrect xmlns:v="urn:schemas-microsoft-com:vml" xmlns:w="urn:schemas-microsoft-com:office:word"
href="https://example.com" style="height:44px;v-text-anchor:middle;width:200px"
arcsize="12%" fillcolor="#2f6f4e" stroke="f">
<w:anchorlock/>
<center style="color:#ffffff;font-family:sans-serif;font-size:16px">Read more</center>
</v:roundrect>
<![endif]-->Microsoft took conditional comments out of Internet Explorer 10 back in 2012. The last ones I’d seen before this job were in WordPress theme headers, loading a shim for IE8. I was glad to be done with them. I type a fresh one most weeks now 🙃
Nobody to send the memo to
So why does none of this get fixed? That’s the part I actually find interesting.
Email is a federated protocol with no version negotiation and no central authority. Anybody can write a client and every client is its own rendering environment. There are a few dozen in meaningful use and hundreds in total, running on operating systems going back decades. Nothing can ever be deprecated because there’s nobody whose job that would be.
Compare that to the web. We complain about it constantly and next to email it’s a tightly run organization.
There are a handful of engines. The people who make them meet, agree on specifications, release features roughly in step, and can remove things when they want to. When a vendor decides something is harmful it goes, and a few years later it’s gone everywhere.
On the web I draft a support matrix and the account manager takes it to the client. Rows drop off the bottom of it as the years pass. Email’s matrix is written for you and nothing ever comes off the bottom.
There’s no way to say “from 2020, clients should support flexbox” because there’s nobody to say it to and no consequence for ignoring it. So the effective standard is the intersection of what every client already does, and an intersection can only shrink or hold still.
I keep turning that over because decentralized is a thing a lot of us say we want, and email is what it looks like 35 years in. I don’t think it’s a failure of will or that anybody defected. There’s just no seat anybody could sit in to make the call, and the protocol rules out inventing one.
Tables all the way down
So you write tables. You nest them and put role="presentation" on each one so a screenreader treats them as the layout they are instead of announcing a data table.
The styles go inline on nearly everything because plenty of clients throw away the document head. Gmail started supporting embedded styles in 2016. The Gmail app signed into a non-Gmail account still doesn’t, and the gap between those two sentences is where a good afternoon goes.
Campaign Monitor keeps a big grid of which CSS works in which client. It’s the nearest thing this corner of the job has to Can I Use, and I have it open more days than not.
In practice you write a stylesheet like a normal person and then run a build step whose entire purpose is to inline every rule onto every element it matches. That’s a tool that exists to undo 20 years of separating content from presentation, and it runs on every build.
Magento does it to its order emails every time one sends, with a library called Emogrifier. I don’t hate it but I do think about it.
Nobody should write the tables by hand and I don’t. We use Foundation for Emails from ZURB, the people behind the Foundation framework.
You write something that looks like a grid system, and its build turns it into the nested tables and does the inlining. That’s the difference between this being a day and this being a week.
<container>
<row>
<columns small="12">
<p>Hello</p>
<button href="https://example.com">Read more</button>
</columns>
</row>
</container>It doesn’t write the VML so the button up there is still mine to type.
And the layout is one column, which is the single thing I’d keep if I could only keep one. Nearly every rendering disaster I’ve had has been a multi-column layout getting creative in one client. One column works everywhere, reads better on a phone, and is where the design lands after two rounds of testing anyway.
That row of three cards became three cards stacked. It already did that on a phone, which is where most of the client’s customers were going to read it.
The parts that get read first
Preview text is the line the inbox shows after the subject, and it’s close to the second most-read text you’ll ever write. By default it’s whatever happens to come first in your HTML. Usually that’s “View this email in your browser.” Put a hidden element at the top with a real sentence in it.
Outlook blocks images by default so a decent share of your recipients read the alt text before they read anything else. An email that’s one big image is a blank rectangle to them. It’s the same argument I was making about alt text on websites a couple years ago, with worse odds.
Then there’s testing, which you can’t do yourself because you don’t own a Windows machine with a few versions of Outlook on it plus a phone with the Gmail app signed into a non-Gmail account. There are services that render your email in all of them and hand you screenshots.
They’re the only reason anybody knows what their email looks like. The testing service is the one line in our tooling nobody has ever asked me to justify.
In defense of 1997
It’d be unfair to leave it there because I think a good chunk of what looks like backwardness is correct.
There’s no JavaScript in email and there never should be. An email is a document sent to you, unasked, by a stranger. It lands in the same place your password resets do. Running arbitrary code out of that is a hard no.
Every restriction that follows from “this is untrusted content from an unknown sender” follows honestly. In February Google announced a version with interactive parts in it. Nobody has asked me for one.
So I’d rather have the tables. I’d rather explain the tables to a client than explain why their newsletter did something ambitious with their reader’s machine.
If you’re about to build one
Most of what I know about this I learned this year, and doing it every week is the only reason any of it has stuck. It isn’t reinforced by anything else I do all day, and it’s specific enough that you can’t reason your way back to it from anything you already know. For the first couple months I had to find every line of VML again before I typed it.
Maybe that’s why so little of it gets written down by people who do client work. At most places it’s rediscovered a few times a year by whoever drew the short straw, and nobody does it often enough in a row to build an opinion worth publishing.
Most of what I’ve found comes from the companies that sell the testing services, which makes sense since they’re the only ones who see every client at once.
If you’re heading in, the short version is to use one column, use a framework and let it write the tables, write the preview text, and buy the testing service. That covers most of it.
The intersection will be exactly where you left it, which is the one restful thing about this medium. Everything else I know goes stale in two years. This hasn’t moved since 2007. Good luck, and go and look at it on a phone before anybody else does.