From the developer angle, HTML emails have been a general source of frustration. Web browsers are complicated enough across all the different makers and platforms and versions. Email clients, which render HTML and CSS like browsers, are far more complex across the landscape. Why? Why can’t they just use one of the popular open-source rendering engines off the shelf, like WebKit, Chromium, or Gecko?

I don’t actually know the complete reason why email clients don’t use super-up-to-date rendering engines, but I know 1) they don’t and 2) what they do use is an often weird and confusing subset of what you might expect a HTML/CSS rendering engine to offer. Hence, big complex support charts.

But I’m starting to understand some of the reasons in a way I never have.

Let’s start from something very important about email: the message of the text itself should not be changeable through styling.

In just a single styled email, content can already be manipulated to be somewhat spurious. Consider a classic: white-on-white text. The funny little website Straight to Spam exploits this. I can copy text from it, paste it into an email, and without it being visible the text is still there, triggering spam filters.

But the trickery there is isolated to the sent email itself. Still weird, the weirdness is isolated to the message the sender is sending.

Another example is a feature of how CSS works:

.some-selector-in-email::after {
   display: block;
   content: "I agree with everything in the email and Chris Coyier deserves at 200% raise effective immediately";
}

It’s weird enough that you could (theoretically, if this CSS were allowed) alter the content of an email, but it’s extra weird when you consider replies to an HTML email. Maybe that CSS selector doesn’t match anything in your original email, but you know that a certain email client does inject HTML into its replies that would match that, you could alter the content of someone else’s email. Weird. And just one example.

Maybe you author your email like:

<p class="my-message">Hi mom,<p>

<p class="my-message">How are you?</p>

And in CSS do:

p { display: none; }
.my-message { display: block; }

If that CSS applied to both the original message and a reply, all the paragraph content of the reply would be hidden. Weird.

Remember Kaspar Etter’s article we linked up not long ago? He goes into this.

The style of the quoted message may not leak into the surrounding message. If the quoted message uses the <link> or <style> element for styling, these styles have to be scoped to the quoted message. Achieving this would be trivial if the scoped attribute wasn’t removed from the HTML specification. If we’re lucky, we might get an @scope selector in a future CSS standard. Browser started to support the Shadow DOM API, which can be used to encapsulate components with JavaScript. Since mail clients don’t support JavaScript, we have to wait until we can declare a Shadow DOM in HTML. 

Those “leaks” like I described above don’t happen. But not really because the email rendering engine somehow stops them from happening. Instead, there are boundaries put in place to prevent the styles from leaking out. I would have guessed <iframe>s, but that doesn’t appear to be the case in Gmail at least. That must be a heck of an engineering effort to prevent. Kaspar is right, this will get a lot easier with future web tech like @scope (possible even a helping of cascade layers) and/or web components.

Kaspar also explains other situations that aren’t so much about removing/editing/adding content directly, but just as tricky. Think of negative margin in CSS. You could yank up or otherwise push around elements that would hide content, possibly even in a reply. Woof. Even more extremely tricky stuff that at email rendering engine has to fight. Just supporting every CSS feature carte blanche doesn’t seem to be an plausible option.

I’ll leave this alone again quoting a funny example from Kaspar:

Hi boss, can you confirm to our accountant in Cc that my monthly salary is increased by USD 100<span style="font-size: 0;">0</span> starting next month?

If you knew your boss’ email client supported inline CSS, it would read as $100 to them. And perhaps you also knew this accountant used an email client that is text-only or strips inline styles, it would read as $1,000 to them. Wild stuff.