Email development has never converged on the browser's relative uniformity. Rémi Parmentier, who runs the Tilt Studio agency in northern France, has been writing HTML email since 2006 and runs workshops and talks on the subject under the handle HTeuMeuLeu. He joined the Smashing Podcast to explain why the discipline looks the way it does — and why it may be about to shift.
Two things that separate email from the web
Parmentier splits the difference between email and web development into two areas. The first is the client landscape: browsers have collapsed into Chromium and WebKit, while email still runs across a wide spread of clients, each with its own bugs, quirks and unexpected features.
The second is the audience. On the web, analytics or server logs tell you who visited and what they viewed. Email offers no JavaScript and no server statistics, since messages live on the recipient's mail service rather than your own. Invisible tracking pixels are the only substitute, and they are unreliable: some recipients never load images, and proxies such as those in Gmail and Apple Mail skew the numbers further.
The practical consequence is that you cannot reason your way to a narrowed test matrix. A developer who knew 90% of readers used Apple Mail could ignore Outlook; an email developer cannot, because the population reading the message is genuinely unknown. The reasonable goal is to get as close to universal as possible, not to code for everyone.
Clients also rewrite the markup itself — adding or altering links, obfuscating content for security and privacy — and those changes sit outside the sender's control.
One vendor does not mean one rendering engine
Families of clients behave inconsistently. Gmail is the clearest current example: desktop webmail generally has the strongest CSS support in the family, mobile apps less, and the combination of a mobile Gmail app with a third-party address the least of all. That last case is known in the community as GANGA — Gmail apps with non-Gmail accounts — and there the client strips many styles for security reasons, offers no support for style tags or media queries, and leaves roughly raw HTML with a few basic styles.
Outlook's Word engine and the Edge beta
Microsoft moved Outlook on Windows from the Internet Explorer engine to the Word engine in 2007, and Word renders HTML and CSS poorly — supporting little, and often calculating things such as image-derived weights incorrectly. This single client is the reason table-based layouts persist in email at all, because Word understands nothing else for layout.
A few months before the conversation, Microsoft published the first public beta of a new Outlook on Windows built on the Edge rendering engine — essentially a web app embedded as a desktop application. Should that replace the Word-based versions across the user base, almost all of the problems Outlook introduced would disappear, and tables for layout would stop being a requirement.
Building fluid first, with Outlook carved out
Parmentier's own approach is the one the industry and community have largely converged on: fluid or hybrid layouts. Layouts are built to adapt to any screen size using ordinary div elements — a div with no fixed width is already responsive — and media queries then refine the result for mobile or desktop. He frames this as progressive enhancement and graceful degradation, a mindset he considers central to email work.
Tables are not abandoned but confined to conditional comments aimed at Outlook, the only client that needs them. Rather than a separate code path for the whole message, small blocks open a table for Outlook at one point and close it at another, with the rest of the markup shared by all clients.
Fuller HTML semantics are less viable. Because a newsletter ends up nested inside another application's HTML — Gmail webmail inserts it into its own interface — tags such as article lose their meaning, and Gmail does not support them in any case, so a fallback is needed.
Why styles are still inlined
Inlining remains advisable because some clients do not support style tags at all — GANGA again being the example — so inlined fonts, colors and text styling are what keep a message readable in the most restrictive environments. Outlook on Windows, contrary to common expectation, does support style tags.
Media queries cannot be inlined, so responsive email inevitably uses style tags as well; the result is a mix of both. Inlining also guards against forwarding and replying, which clients handle by stripping style tags from the message. Without at least a minimal inline layer, a forwarded email can arrive looking broken.
Web fonts are a narrow enhancement rather than a baseline. Apple Mail supports font-face and does not apply CORS rules, so fonts restricted on the web still load there; Gmail, outlook.com and Yahoo do not support font-face at all, and only a handful of smaller or regional clients do. When a client does fetch the font, CORS restrictions configured on a client's own hosting can produce errors — yet for email applications those restrictions do not apply, so Apple Mail will still render the font. The design decision follows from the support gap: treat custom fonts as an enhancement and decide in advance what happens when they do not load.
Tooling: MJML, Parcel and Maizzle
MJML, the templating language launched by Mailjet, remains popular; Parmentier consulted on it around 2015–2016 to make its HTML output hold up across environments including Outlook, and its mobile-first approach has aged well, though it has been updated since. He does not use MJML personally but has spent the year working with Parcel, an online code editor for HTML email offering components, style inlining and the ability to send test messages to an inbox directly from the editor, and with Maizzle, a Node framework for building HTML email that he compares to Jekyll or Eleventy — you bring your own code and it handles routines such as style inlining.
Testing shortcuts
Sending to yourself is still the first line of defence, in Parmentier's case to dozens of addresses created across providers so he can observe how code behaves per client. Beyond that, email screenshot tools work like BrowserStack for email: paste or send the HTML code and receive screenshots across many clients — Apple Mail, iOS, Gmail, Outlook on Windows — giving a fast preview of rendering differences in a few clicks.
Can I Email and the state of feature support
Can I Email, announced at SmashingConf Freiburg in 2019, was built to fill a gap: earlier documentation of CSS support across clients lived in outdated blog posts or static pages. The site is open source and community-contributed, so a client that fails to support something can be reported and the knowledge is shared — a public, editable knowledge base in the spirit of Can I Use for email. (Parmentier is on Twitter as HTeuMeuLeu.)
Subgrid arrives via Safari, not the web platform generally
CSS subgrid should reach Apple Mail in the following release, since every WebKit and Safari addition tends to carry over, putting support somewhere around the end of the year. Outside Apple Mail it will not be available. JavaScript, by contrast, should not be expected and is not desirable: a single line of script inside a client could let an attacker reach an entire inbox and exfiltrate data without the user noticing, so full JavaScript support will never arrive.
What interactive email can actually do
CSS-based interactivity is the traditional route, limited to what :checked and :hover enable — content appearing on hover, image swaps, and more elaborate click-driven reveals. Support is decent: Outlook.com and Yahoo desktop webmail handle these interactions, and Gmail supports hover.
Google's AMP for Email took a different path, introducing a new MIME type alongside the plain-text and HTML parts of a message and adding an AMP section to the email code. That made support a prerequisite: sending an AMP email requires the email service provider to handle the MIME type, and many prominent providers, MailChimp among them, do not. Even after sending, the sender must be whitelisted with each supporting client — Google for Gmail webmail, and others — making the process difficult and running against email's open nature, where anyone can send and any client can read. A Google Docs comment notification that can be answered from inside Gmail's inbox remains the standout use case; broader adoption is hard to picture, and hard to reconcile with how ordinary email works.
The Email Markup Consortium
A newer effort is the Email Markup Consortium (EMC), a group of email developers, marketers and designers formed in the preceding year and made public the month before the conversation. Its aims are standardisation and uniformity across clients for developers, and better support for ARIA roles and properties plus responsive images for users — the latter making lighter, more performant email possible through smaller image sizes. Parmentier credits Marc Robbins and Alice Li as the main organisers, alongside other active Email Geeks contributors. The group spent a year working quietly before launching and is now trying to get client developers to improve their implementations; several clients have already expressed interest, including a German client. Past attempts at improvement have fizzled, which is why he is watching this one closely. The wider community hub is Email Geeks, which has a Slack channel where members of the group can be found.
A dreamed-of feature, and getting started
Asked for one feature he would want in every client tomorrow, Parmentier picks something outside HTML and CSS: reactions, of the kind Slack, GitHub issues and iOS and Android messaging offer. A reaction would replace a great many acknowledgement emails, and would require substantial standardisation and implementation to work — so it is not close.
For newcomers, starting from a template provided by an email service provider is a reasonable route: learn from it, notice where it falls short, and improve on it. That choice mirrors web development, where the decision between a framework or default theme and building from scratch comes down to available time, knowledge, will and patience. And for web developers frustrated by the state of the web, the invitation stands: there is a whole community on the email side, and by Parmentier's count there are dozens of them.
