Why Does HTML Email Still Feel Like 2005?

Why Does HTML Email Still Feel Like 2005?

Because email has no shared rendering standard and no way to fix old clients. A web page runs in a browser that updates itself. An email runs in whatever the reader happens to open it in, and some of those clients render HTML with software that was never meant to render HTML.

That is the whole explanation. It is not laziness on anyone's part, and it is not solved by a framework. It is a distribution problem, and it is finally starting to improve.

We build lifecycle and campaign emails alongside marketing sites, and the questions we get are always the same four: do I still need tables, does Gmail read a style block, what CSS is safe, and how do I test this. Here are our answers, with the vendor documentation behind each one.

Which Email Clients Do You Actually Have to Support?

Three, for almost every B2B audience. Litmus publishes market share from its own Email Analytics product, and its July 2026 figures, calculated from over 1 billion opens, put Apple at 62.26%, Gmail at 27.03% and Outlook at 5.83%.

Litmus is clear about where that comes from: "real-life Litmus customers who are using Litmus Email Analytics in their own emails," with opens anonymised and containing no personally identifiable information. So it is a large sample with a known bias toward companies that buy email tooling, which is roughly your audience anyway.

The practical reading is that Apple and Gmail together account for close to 90% of opens, and Outlook is small but disproportionately important because it skews to the corporate inboxes where your buyers sit. Chasing the long tail below that is rarely worth the hours.

Do You Still Have to Build Emails With Tables?

For anything that must look right in classic Outlook on Windows, yes. For everything else, less than you think, and the reason is a genuine architectural change.

The Email Markup Consortium describes the history plainly: "For years, the Outlook for Windows desktop apps relied on proprietary technology to render HTML emails: their own Microsoft Word." That is why the table habit exists. Word was never a browser, and it did not track HTML specifications.

The same organisation notes the change: "The new Outlook for Windows brings a fundamental change. It no longer uses Microsoft Word as a rendering engine, but a normal web browser engine," with handling of HTML and CSS features close to the web version of Outlook. As the Word-based client's share falls, the table workarounds stop being mandatory. They are not gone yet, because classic installs persist in enterprises, but the direction is one way.

Does Gmail Support a Style Block or Not?

It does, and this is the single most common piece of outdated advice in email development. Google's own Gmail design documentation says you "can style email sent to Gmail using inline style blocks and standard CSS," and that "most CSS selectors, attributes, and media queries are supported."

It also names which selectors work: "Gmail supports class, element, and ID selectors." So a stylesheet in the head with classes is fine. You do not have to inline every declaration by hand.

What Gmail does is ignore what it does not support. Its documentation says Gmail "might ignore unsupported CSS properties and selectors," which is the polite failure mode: your layout degrades rather than exploding. That is worth designing for deliberately, by making sure the unstyled version is still readable.

What CSS Can You Rely On?

Read the published support list rather than guessing. Gmail's documentation includes an explicit list of supported properties, and it is longer than most people assume: it covers the border family including border-radius, background and background-image, the font family of properties, padding and margin, max-width and min-width, opacity, display, float, table-layout, vertical-align, and text-decoration among many others.

Just as useful is what is absent. Gmail's published property list does not include the flexbox or grid properties, and it does not include position. So a layout built on flex or absolute positioning is not something Gmail promises to render. Use nested block elements with widths and padding instead, or tables where the client demands them.

Media queries are supported but narrowly. Gmail lists the types all and screen, the queries min-width, max-width, min-device-width, max-device-width, orientation, min-resolution and max-resolution, and the keywords and and only. That is enough for responsive layout and nothing more.

How Do You Handle Dark Mode?

Defensively, and without relying on a media query. Notice what is missing from the Gmail list above: prefers-color-scheme is not among the media queries Gmail's documentation says it supports. Several clients also recolour your email on their own, whether you asked or not.

So the durable approach is to build an email that survives being inverted. Use transparent PNGs for logos rather than white backgrounds that become white islands. Avoid pure black text on pure white if you can, since both ends get remapped. Do not put critical text inside an image, because nothing will adapt it. And give buttons a solid background colour with sufficient contrast in both directions.

We take the same posture we described for websites in dark mode web design: decide what must not change, protect that, and let the rest adapt. In email you have far less control, so the list of things you protect should be short.

What About Images That Do Not Load?

Assume some readers see none of them. Many clients block remote images until the reader asks for them, so your email has to make sense as text plus alt attributes.

That means real alt text on every meaningful image, an empty alt attribute on decorative ones so screen readers skip them, and a background colour behind any image that sits on a coloured block, so the layout does not collapse into white boxes. It also means your headline should be live text, not a rendered graphic, which helps accessibility and search-style preview snippets at the same time.

The discipline is the same one that makes web pages robust, and we wrote about the automated end of it in using AI for alt text without making things worse.

How Do You Test Without Fifty Accounts?

Test three clients properly and spot-check the rest. Apple Mail on iOS, Gmail in a browser, and Outlook in whichever version your customers actually run will catch the overwhelming majority of problems, because those three cover close to 95% of opens in the Litmus data.

Then send yourself a real email, every time, before the campaign goes out. Not a preview inside the tool: an actual send to real accounts. Preview renderers are useful and they are not the same as a delivered message, because they skip the parts that break in transit, like a marketing platform rewriting your links or mangling a long style block.

Keep a short checklist rather than a long one. Does it read with images off? Does it read inverted? Does the preheader text say something useful? Do all links point at the right place with the right tracking parameters? Four questions catch most of it.

What Should the Build Process Look Like?

Treat the email as a build artefact, not a document someone edits in a WYSIWYG panel. Keep the source in version control, keep the content separate from the template, and generate the final HTML.

In practice that means one template per email type, with tokens for the parts that change, reviewed once properly and then reused. The alternative, where every campaign starts by duplicating last month's email and editing it in the platform, is how you end up with six slightly different templates and a broken one nobody noticed.

If your emails carry lifecycle logic rather than one-off campaigns, the template inventory matters even more, which is the structural point we made in building a SaaS lifecycle email framework.

Is This Worth Doing Well?

For B2B, yes, because email is the one channel you own. Search visibility changes when someone else changes an algorithm. Social reach changes when someone else changes a feed. An email list is a direct line, and the quality of what arrives in the inbox is one of the few things entirely within your control.

The encouraging part is that the ground is moving in your favour. The Word rendering engine's retreat is the biggest improvement in email development in fifteen years, and Gmail's support list is broader than the folklore suggests. A team that reads the two published support documents instead of copying a 2014 template will build something better in less time.

The unglamorous part is that testing is still manual, and no amount of tooling removes the step where a person looks at a real email on a real phone. Budget for that step. It is the one that catches the embarrassing mistakes, and deliverability work only matters if the message renders once it arrives, which is why we treat it alongside B2B email deliverability.

If you want your email templates rebuilt properly once so that your team can stop firefighting them, we are happy to help. You can find us at phoenix.studio.