The Web Technology That Time Forgot
HTML email development is the part of web development that routinely surprises developers who encounter it for the first time after years of working with modern web technologies. The expectation — that writing HTML and CSS for an email would be similar to writing HTML and CSS for a webpage — meets the reality: email clients render HTML using engines ranging from the relatively modern (Apple Mail, which uses WebKit) to the genuinely ancient (Outlook for Windows on older systems, which uses Microsoft Word’s HTML rendering engine for certain email versions). This fragmented, backwards-compatible rendering environment means that email HTML development is constrained by what the worst-supported client can render rather than by what modern HTML and CSS can do.
Understanding why this situation exists explains the specific constraints that email HTML development works within and why the workarounds that experienced email developers use look archaic to developers accustomed to modern web development.
Why Email Clients Render Differently
Web browsers have converged on modern HTML and CSS standards through competitive pressure (browsers that didn’t implement standards lost users and market share) and through standards bodies that produced specifications browsers converged on. Email clients have faced different pressures: their primary function is message delivery and reading rather than HTML rendering capability, their user bases don’t typically switch clients based on HTML rendering quality, and adding full CSS support to the Word rendering engine that Outlook uses is a significant engineering investment with uncertain ROI.
The result: Outlook for Windows (on older versions) renders certain HTML elements using Microsoft Word’s layout engine rather than a web browser engine, which lacks support for many CSS properties, renders background images unreliably, handles floats and positioning differently from browsers, and ignores many modern CSS features entirely. Gmail strips certain CSS, particularly CSS in <style> tags (though this has improved in recent years). Outlook.com, Apple Mail, iOS Mail, and Android’s email clients each have their own support profiles. Developing for email means designing for the intersection of what all of these support.
The Table-Based Layout That Still Dominates
The approach that produces the most consistent email rendering across the widest range of clients is layout using HTML tables — the same structural approach that web developers used before CSS layout in the early 2000s. Table-based layout renders consistently in email clients because table rendering is one of the oldest and most widely supported HTML features; it predates CSS layout and is supported even in email clients that don’t support modern CSS properties.
This is genuinely unintuitive for modern web developers: writing nested tables with explicit cellpadding, cellspacing, and border attributes, using inline styles rather than stylesheets, and avoiding flexbox, CSS grid, and many other modern CSS features feels like time travel. It’s the correct approach for maximum email client compatibility. MJML, Email on Acid’s tools, and Mailchimp’s template builder abstract this table-based layout behind cleaner authoring interfaces that generate the compatible HTML automatically.
The Modern Email Toolkit
MJML (free, open source, maintained by Mailjet) is the most widely adopted modern email authoring framework: it provides a semantic markup language for email components (mj-section, mj-column, mj-text, mj-image) that compiles to the table-based HTML that email clients require. Writing MJML is significantly cleaner than writing raw table-based HTML; the compiled output handles the cross-client compatibility concerns automatically.
Foundation for Emails (by Zurb, free, open source) provides a similar HTML email framework alternative to MJML with slightly different syntax and compiler options. Email on Acid and Litmus are the primary email preview and testing services: they render email templates across 70+ email clients and provide screenshots that reveal rendering differences before sending, without requiring subscriptions to every email client. Litmus ($99+/month) and Email on Acid ($73+/month) are significant ongoing costs justified for teams sending campaigns regularly; for occasional senders, free preview tools (mail-tester.com for spam testing, Htmlemail.io for basic preview) provide limited but useful preview capability.
Testing and Deliverability: The Two Things That Actually Matter
After producing cross-client compatible HTML, the two factors that determine whether an email campaign is effective: testing (verifying that the email renders correctly in the clients your audience uses) and deliverability (whether the email reaches the inbox rather than the spam folder). Testing uses the preview services described above; deliverability requires technical configuration and content review.
The technical deliverability requirements (SPF, DKIM, DMARC configuration) are covered in the Digital Marketing section of Vol. 2. For HTML email content specifically: images-to-text ratio (emails with too many images and too little text are more likely to be filtered as spam), subject lines that avoid spam trigger words (excessive capitalisation, specific word patterns that spam filters flag), and list hygiene (removing bounces and unsubscribes promptly to maintain a healthy sender reputation) are the content-side deliverability factors within the email developer’s control.