Caniemail.com – like caniuse but for email content

Original Article ↗ Hacker News Discussion ↗

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.).