Crafting HTML Emails: Coding HTML Emails: A Modern Perspective

HTML email is a part of pretty much every project, but even many of the most experienced web developers dread having to work with it. This series of tutorials will explore the ins and outs of coding modern HTML emails, showing you how to love the craft rather than fear it.

Email Isn’t Dead

Email was born in 1971. And it died in 2007, according to FastCompany. Or in 2009, according to The Wall Street Journal. Or maybe it was in 2011, according to Mark Zuckerberg. No one really seems to know.

What we do know, however, is that email is still highly effective:

• “Email drives an ROI of $36 for every dollar spent”, according to email marketing platform Litmus.
• Four billion people use email daily, according to data platform Statista.
• In 2021, 41.5% of brands interrogated in the Litmus State of Email report consider email marketing to be critical to company success—an 8.7% increase from just three years earlier.

The following diagram shows the percentage of brands for whom email marketing is critical to success, rising from 32.8% in 2018 to 41.5% in 2021.

According to Harvard law professor Jonathan Zittrain (quoted by The Atlantic), one reason email is still so strong after all these years is that “Email is the last great unowned technology”. This arguably makes it more resilient and robust than any proprietary technology. So it certainly seems that email is here to stay!

HTML Emails Aren’t Stuck in the 1990s

Discussions surrounding the coding of HTML emails on social networks never fail: someone will always snarkily comment on how HTML emails are stuck in the 1990s. And there’s nothing that irritates me more—because it’s completely wrong!

A collection of snarky comments is pictured below, sourced from my 2019 “ Think Like an Email Geek ” presentation.

When I code an HTML email, I use plenty of modern styles: media queries (including ones for dark mode), CSS gradients and background images, Flexbox, and even CSS Grid. I also use semantic HTML: heading elements (<h1>, <h2>, …), paragraphs (<p>), and lists elements (<ul>, <li>).

But I also use tables—because it’s still largely recommended to use tables for layout in HTML emails. But the one and only reason for this boils down to one single word: Outlook. Or, rather, three words: Outlook on Windows. (The other Outlook apps—on macOS, iOS or Android—use either WebKit or Blink and are really fine.) In 2007, Microsoft decided to switch the underlying rendering engine of its mail application from Internet Explorer to … Word. And Word is not really good at rendering HTML and CSS. So the most robust and safest way to tame Word is to use tables.

Still, this doesn’t mean we have to impose tables on everyone, in every email client. In 2015, email developer Nicole Merlin published a foundational article detailing how to create a responsive email without media queries, using <div> s and conditional comments for Outlook on Windows.

The world of email clients has kept moving ever since. Later that year, Yahoo fixed a bug preventing the use of media queries. In 2016, Gmail followed along and added official support for media queries in almost all its email clients. Outlook.com has been rebuilt, twice—first in 2015, then again in 2018. Apple Mail has never ceased enriching its rendering engine with things we barely use even on the Web, from backdrop-filter() to CSS Scroll Snap.

In 2018, JavaScript partially made its entry into emails via dedicated frameworks (Adaptive Cards for Outlook clients, and AMP for Email in Gmail, AOL, Yahoo Mail and Mail.ru). And then, in 2019, email clients turned to the dark side with the arrival of dark mode and partial support for @media (prefers-color-scheme) media queries. The Gmail apps (on iOS and Android) even got an auto dark theme feature, years before Chrome got its own.

Defining an Email Client

Outlook is not an email client. Neither is Gmail. Nor is Yahoo. Yet I hear angry bosses or helpless developers complain about their email being broken in Outlook all the time. So what’s wrong with this?

The thing is, rather than being an email client, Outlook is a brand name. It’s a group of different email clients. There’s Outlook on Windows, Outlook on macOS, Outlook on iOS, Outlook on Android, and Outlook.com on the Web. Each of these email clients has its own rendering engine (for example, Word for Outlook on Windows, WebKit for Outlook on macOS), its own filters and HTML and CSS restrictions, its own set of features, and its own bugs.

It’s a similar situation with Gmail. There’s Gmail’s desktop webmail, its mobile webmail, its iOS app, and its Android app. Gmail’s webmail versions use the rendering engine of your browser (Blink for Chrome, WebKit for Safari, Gecko for Firefox). The mobile apps use the operating system’s default web view engine (WebKit for iOS, Blink for Android). But then, each of these email clients has its own variation of HTML and CSS support. And the most egregious example of this is that, in Gmail’s mobile apps (on iOS and Android), you get one level of CSS support if you’re using a Gmail account (with an @gmail.com email address or on your own Google Workspace), but a different level of support if you’re using a third-party email address (like an @outlook.com or @yahoo.com email address). And in the latter case, that’s pretty much the worst level of support possible, with no <style> tags and no media queries!

A few years ago, I started drawing diagrams of CSS support across all Gmail clients to get a better understanding of this support and better explain it to colleagues and fellow email developers. And while things have certainly improved in the past decade for Gmail, it’s still something unexpected and surprising for newcomers.

The diagram below shows the different levels of CSS support for Gmail clients.

In 2017, email marketer Chad Whiteestimated that every email “has approximately 15,000 potential renderings (and that’s using conservative math)”. And that was before dark mode, and not even taking accessibility into account. Personally, I consider that each recipient of an email will have a unique way of viewing it.

So if you’re writing a brief for an agency about which email clients you want to be supported, or if you’re giving feedback to your email developer, or if you’re developing software related to email clients, make sure to always provide each client’s full name, together with its family, its platform, and (when available) its version.

“Email Developer” Is a Job

When I started web development as an amateur in the late 1990s, the Web was all the rage. It was so exciting to be able to publish your own web pages, laid out with bare HTML and maybe just a touch of CSS. Later generations of developers got excited over mobile platforms (in the late 2000s), and then over JavaScript frameworks (in the late 2010s). But no one really ever got excited about being an email developer. No one really wakes up one day thinking “I can’t wait to code HTML emails”. Even if you’ve looked keenly at newsletters from a designer’s or author’s perspective, you probably haven’t done so from a developer’s one. You don’t really plan to become an email developer. It sort of happens to you.

Email marketer Justine Jordan captured this perfectly when she popularized this saying:

You don’t choose email. Email chooses you.

It was even turned into a T-shirt by email developer Anne Tomlin.

The role of email developer is a job. And it’s one that I’m very proud of.

It’s one of the last refuges for those interested in HTML and CSS, but not really JavaScript. And it’s a great area to focus on for those who code and care about interoperability, accessibility, maintainability, and graphic design.

Email development is a craft of its own. We should embrace its quirks and weirdness and use its unique abilities. And we should stop comparing it with web development. It’s a trap to believe that because you can use HTML and CSS in emails, you should be able to use any HTML and CSS.

Email client support for HTML and CSS is a spectrum that spans from Apple Mail at the top—which supports 200 HTML and CSS features—to Outlook on Windows at the very bottom—which supports only 51, as shown in the Email Client Support Scoreboard from Can I email.

If you’re ready to face the unexpected, I can assure you coding emails will become a joyride—even if a wild one!

Conclusion

Our journey into the world of HTML emails is just getting started. In the following tutorials, we’ll cover a lot of tips and tricks for tackling the vagaries of email clients, and also for making our emails more accessible and even interactive!

Although we’re going to stay focused on the coding and development side of HTML email, there’s a whole lot more to explore around this topic—from design to strategy and deliverability. Here are three of my favorite links for diving deeper into all that:

• Really Good Emails. A collection of over 9,000 curated emails from the world’s top companies. And most emails also come with their HTML code!
• Email Resources by email developer Avi Goldman. Features over 400 up-to-date links to resources about email, from copywriting and design to code and deliverability.
• The #emailgeeks Slack channels. Over 12,000 email professionals chat, share, and help each other all week long across dozens of channels (covering code, design and marketing). You may find me over there quite often in the #email-code channel!

In our next tutorial in this series, we’ll review some of the most important tips and tricks for coding robust emails across email clients.