Email Is the Browser War That Never Ended — and Never Will

Open an email template file in 2026 and you'll find a nested HTML table three levels deep, a conditional comment block starting with <!--[if mso]>, and a VML shape hack faking a rounded corner because border-radius isn't reliable in the client that's about to render this thing. Nothing about the surrounding code has moved since roughly 2009. You didn't write it that way out of nostalgia. You wrote it that way because it's still the only thing that survives contact with Outlook.

That discomfort is the whole story. Everywhere else in front-end work, 2026 CSS is remarkably boring in the best way — flexbox, grid, container queries, :has(), all of it just works, across engines, without a build step or a fallback plan. Email is the one surface where none of that convergence happened. Client-side rendering for email is structurally more fragmented today than desktop browser rendering ever was during the actual browser wars, and almost nobody writes about it anymore, because it stopped being an interesting problem to complain about. It's just background weather now. It still breaks a template every week.

The Dual-Outlook Problem Nobody Budgeted For

In January 2025, Microsoft pushed the auto-migration to the new Outlook, and instead of retiring the old rendering engine, it created a second live one. The legacy Outlook still runs on Word's HTML engine, not a browser engine, and it remains installed across a huge share of enterprise environments that aren't going to be forced onto new hardware or new IT policy on Microsoft's timeline. The new Outlook runs on Chromium instead. So as of last year, a single email template has to render correctly on two Outlooks that don't share a rendering pipeline, don't share a CSS support profile, and aren't going away from each other any time soon.

Neither engine is being sunset. That's the part that makes this different from a normal version-support decision. Browsers deprecate old engines because users upgrade or the vendor forces the upgrade. Outlook can't do that cleanly, because a meaningful share of its install base sits inside enterprise environments where IT controls the update cadence, not the end user, and IT has no particular urgency about a rendering engine most of the organization has never heard of. The result is two live, permanent targets instead of one target in transition.

This is why the table-and-VML fossils haven't been retired. The Word engine still doesn't reliably support flexbox, border-radius, or background-image — the same three properties that have been trivially safe in browsers for over a decade. A rounded button corner needs a VML rounded-rectangle shape wrapped in a conditional comment targeting mso, sitting next to a modern border-radius declaration for every other client, because you're not choosing one rendering model anymore. You're maintaining two, permanently, inside the same send. Nobody shipping email templates got a migration guide for this. They got a support ticket queue full of layouts that broke overnight for no code change on their end.

Why Gmail Deletes Your CSS Before Anyone Sees It

Outlook isn't even the whole problem. Gmail sanitizes incoming HTML on ingestion, and that sanitization strips a meaningful share of the CSS a designer actually wrote before the message ever reaches a rendered inbox. Certain selectors get dropped. Portions of <style> block content get filtered out depending on what Gmail's parser decides looks unsafe or unsupported that week, and that decision isn't published anywhere you can audit against. You can write clean, valid, modern CSS and have a meaningful fraction of it simply not arrive.

That's a different failure mode than "old client, old engine, expected fallback." Gmail is not a legacy holdout running 2009-era rendering. It's the dominant consumer inbox, actively maintained, and it still treats your <style> block as untrusted input to be pruned rather than rendered. Email rendering audits — Mail Genius's ongoing compatibility tracking is one of the more thorough ones — consistently find that the vast majority of sent emails carry at least one serious rendering or compatibility issue by the time they hit a real inbox. Not an edge case. The default outcome, across a normal send.

And the cost isn't abstract. Roughly 42% of recipients delete a poorly rendered email immediately, without reading past the broken layout. That's not a developer's aesthetic complaint about legacy markup. It's a direct, measured revenue leak sitting downstream of a rendering problem most teams have quietly decided isn't worth relitigating anymore.

That decision to stop relitigating it is itself worth noticing. Around 2015, email rendering compatibility was a live topic. Litmus and Email on Acid built entire businesses on preview-and-test tooling, conference talks walked through the table-layout workarounds, and there was a shared sense that this was a temporary embarrassment the industry would eventually engineer its way out of. A decade later the tooling still exists, the workarounds are unchanged, and the conversation about it has mostly gone quiet. Not because it got solved. Because everyone building email templates for a living made peace with a permanent workaround and stopped expecting anything else.

The Convergence That Never Came

Compare this to what actually happened with browsers. The browser wars ended because Chrome, Firefox, Safari, and eventually Edge were all competing for the same users, and standards compliance became a competitive advantage rather than a cost center. Interoperability initiatives like Interop 2026 exist precisely because vendors have skin in the game — a browser that renders the modern web incorrectly loses market share to one that doesn't. That pressure is what turned container queries, anchor positioning, and a dozen other features into boring, universal, Baseline-supported reality inside a few years. Browsers converged because divergence was expensive for the vendor, not just the developer.

No equivalent pressure exists for email clients. Nobody chooses Outlook over Apple Mail because Outlook renders CSS grid more faithfully. Nobody switches inboxes over a border-radius bug. The rendering engine is invisible to the person deciding which email client to use, so there's no market mechanism punishing Microsoft or Google for shipping inconsistent CSS support, and there never will be. Layer enterprise inertia on top of that. Companies run Outlook builds for years past their intended lifecycle because migrating an org's entire mail infrastructure is its own multi-year project, not a weekend patch cycle, and nobody schedules a multi-year project to fix something users aren't complaining about. You get a rendering environment where the old engine can't be deprecated even by the vendor that owns it. The dual-Outlook problem isn't a transitional hiccup on the way to convergence. It's what permanent non-convergence looks like from the inside.

So Actually, This Was Never a Technical Problem

The instinct is to treat email rendering fragmentation as a solvable engineering gap — as though the right polyfill, the right template framework, the right VML technique will eventually close it the way autoprefixer and Babel closed the browser gap. It won't, because the browser gap closed for economic reasons, not technical ones. The CSS features existed in spec form for years before any browser shipped them consistently. What changed was the incentive to ship them, and that incentive came from competition nobody can manufacture inside the email client market.

So the honest framing isn't "email CSS support is behind and catching up." It's that email rendering sits outside the mechanism that produces catching-up at all. Table layouts and VML hacks aren't a temporary embarrassment on their way out. They're the correct response to a market structure that has no reason to change, which means the skill of writing 2009-era markup inside a 2026 codebase isn't a fossil craft waiting to go extinct. It's a permanent part of the job, for as long as there's an inbox on the other end.

The Part That Stays

Every other corner of the web got to grow up. Email design got frozen at the exact moment convergence stopped being anyone's incentive, and it's been building templates for that frozen moment ever since — competently, carefully, and completely aware that the ground underneath it will never move again.