Email client support

What @cascivo/email can and cannot use, derived from the Can I email support matrix rather than asserted by hand. This page and the conformance lint read the same data, so they cannot disagree.

Snapshot: Can I email api 1.0.4, tested 2026-08-10 15:16:24 +0000. Refresh with pnpm email:caniemail:refresh and commit the diff.

How to read the verdict

Symbol	Meaning
✅	Supported by every client in the floor.
⚠️	Partial in at least one client — usually "works on a table cell, not a div". Allowed, and enforced by structural invariants rather than by feature support.
❌	Not supported by at least one client. The lint blocks it.
—	Not in the matrix. Foundational HTML like `<td>` and `<a>` lands here; it is not a failure.

The support floor

A feature must work in all of these for @cascivo/email to use it:

Outlook (Windows)
Outlook.com
Gmail (desktop webmail)
Gmail (Android)
Gmail (iOS)
Apple Mail (macOS)
Apple Mail (iOS)
Yahoo! Mail (desktop webmail)

Outlook (Windows) is the binding constraint. It renders with the Word engine, it fails most modern CSS, and it is the one client that cannot be tested in-house — no emulator exists. It is in the floor precisely for that reason: the lint is what stands between the generator and a broken Outlook render.

Feature support

Feature	Verdict	Outlook (Windows)	Outlook.com	Gmail (desktop webmail)	Gmail (Android)	Gmail (iOS)	Apple Mail (macOS)	Apple Mail (iOS)	Yahoo! Mail (desktop webmail)
Flexbox	❌	❌	✅	✅	⚠️	⚠️	✅	✅	✅
CSS Grid	❌	❌	✅	✅	⚠️	⚠️	✅	✅	✅
`gap`	❌	❌	⚠️	⚠️	⚠️	⚠️	✅	✅	❌
Custom properties (`var()`)	❌	❌	❌	❌	❌	❌	✅	✅	❌
`oklch()` / `lab()`	❌	❌	❌	❌	❌	❌	✅	✅	❌
`color-mix()`	—	—	—	—	—	—	—	—	—
`rem` units	❌	❌	✅	✅	✅	✅	✅	✅	❌
`border-radius`	❌	❌	✅	✅	✅	✅	✅	✅	⚠️
`box-shadow`	❌	❌	✅	❌	⚠️	⚠️	✅	✅	❌
`@media`	❌	❌	⚠️	⚠️	⚠️	⚠️	✅	✅	⚠️
`prefers-color-scheme`	❌	❌	✅	❌	❌	❌	✅	✅	❌
Inline SVG	❌	❌	❌	❌	❌	❌	⚠️	✅	❌
`position`	❌	❌	⚠️	❌	❌	❌	⚠️	⚠️	⚠️
`float`	❌	❌	✅	✅	⚠️	⚠️	✅	✅	⚠️
`padding`	⚠️	⚠️	✅	✅	✅	✅	✅	✅	✅
`background-color`	✅	✅	✅	✅	✅	✅	✅	✅	✅
`border-collapse`	✅	✅	✅	✅	✅	✅	✅	✅	✅
`vertical-align`	✅	✅	✅	✅	✅	✅	✅	✅	✅
`<table>`	✅	✅	✅	✅	✅	✅	✅	✅	✅

Accepted exceptions

A blocked feature may still be used when its absence degrades rather than breaks — the email stays legible, correct and actionable in the client that lacks it. This is the whole list:

`css-at-media`

Outlook Windows is the only floor client that reports n, and it is the one client that never needs the rule: it is desktop-only, and every media query this package emits narrows a fixed-width layout below a phone breakpoint. Absence there degrades to the same fixed 600px layout Outlook rendered before the rule existed. The alternative — no media query — is a 600px table in a 320px viewport, which is a measured 280px of sideways scroll for every mobile reader, so the trade is not close.

`css-border-radius`

Outlook Windows and Yahoo render square corners. Buttons, cards and badges stay fully legible and clickable — only the corner shape is lost. The alternative is a VML v:roundrect per button: ~400 bytes each, unable to inherit the anchor styles, and a second implementation of every button to keep in sync. Square corners in two clients is the better trade.

What this does not tell you

The matrix reports feature support. It does not reproduce a client's own rendering quirks, and no offline tool can: the Word engine is a proprietary Windows binary with no emulator. That residual is bought down by construction — the primitive set is built so it cannot emit what Outlook lacks — plus a release-time manual pass. See docs/specs/email-target.md §4.2 and §5.

As Markdown: /docs/email-client-support.md

← All guides