Caniemail.com – like caniuse but for email content

Original Article ↗ Hacker News Discussion ↗

Email developers are highlighting caniemail.com, a “Can I Use?”-style resource that catalogs how different email clients support (or fail to support) HTML and CSS features, revealing that dominant clients like Gmail and Outlook rank poorly for standards compliance. The exchange quickly broadens into a debate over HTML versus plain-text email, touching on accessibility, security, privacy, tracking, and the practical needs of non-technical users who expect rich formatting and inline images. Participants also trade tools and techniques—such as MJML, Litmus, and testing services—to cope with fragmented rendering engines, dark-mode quirks, and the lingering “IE6-era” constraints of modern email.

Purpose and Scope of Caniemail

  • Catalogs HTML/CSS/email-feature support across many email clients, analogous to caniuse for browsers.
  • Focus is on content rendering, not deliverability, encryption, or protocols.
  • Users appreciate being able to invert the view: see what’s universally supported vs. mixed.
  • Some find the feature matrix so restrictive that “Can I email?” often feels like “no.”

Email Client Support and Fragmentation

  • Popular clients like Gmail and Outlook rank near the bottom in feature support; Apple Mail clients rank near the top.
  • Intersection of universally supported features is tiny: basic table tags, core text elements, a few units, and JPG/PNG images.
  • Outlook is widely described as “the IE of email,” with long‑standing quirks (Word/IE engines, inconsistent padding/width).
  • SVG support is notably absent in Gmail; reasons debated (JS support in SVG, historical XML DoS issues).

Tools and Frameworks

  • Several services emulate “BrowserStack for email”: Litmus, testi.at, Email on Acid, InboxMonster, etc., often integrated into ESPs like Mailchimp.
  • Higher‑level frameworks (MJML, react-email, Foundation for Emails, jsx-email) help generate more compatible HTML, though they can bloat markup and trigger Gmail clipping.
  • Some users still prefer hand‑tuned, minimal HTML to keep size and complexity down.

HTML vs Plain Text (and Alternatives)

  • Strong split:
    • One camp wants plaintext-only (often with images blocked) and views HTML as a historical mistake tied to spam, tracking, and complexity.
    • Another argues the “battle was lost 25 years ago”; average users want inline images, basic layout, lists, and readable receipts.
  • Many advocate a middle ground: markdown-like or gemtext-style minimal formatting, possibly plus inline images, without full CSS/JS.
  • RTF, text/enriched, or a constrained HTML subset are mentioned as missed opportunities or underused standards.

Security, Privacy, and Tracking

  • HTML email is linked to tracking pixels, long tagged URLs, and potential attack surface from browser engines.
  • Some argue we should fix standards and sandboxing rather than “kneecap” email to plaintext.
  • Remote resources and features like :visited raise privacy concerns, though modern browsers limit what can be done.
  • JavaScript in email is effectively unsupported and widely viewed as undesirable.

Other UX Issues and Observations

  • Dark mode behavior is described as especially painful; Gmail is singled out for automatic, uncontrollable color inversion.
  • Many note that most human‑written work email uses very little formatting; rich layouts are mostly from marketing.
  • Some lament lack of coverage for open-source clients (Thunderbird, K‑9, FairEmail, Roundcube, etc.).