Every major email client strips <script> tags before rendering a message — no exceptions, no per-sender opt-out. So when an email carries a working carousel, an accordion that expands, or a quiz that scores an answer, none of it is JavaScript. It's a hidden checkbox, a CSS selector, and a technique the email-development community calls a state machine.
The problem: email clients strip <script>
Web interactivity almost always assumes JavaScript is available. Email can't make that assumption at all — Gmail, Apple Mail, Outlook, and every other major client removes <script> tags on arrival as a baseline security measure, regardless of what a sender includes or how the message is signed. Anything that behaves like an app inside an email has to be expressible entirely in HTML and CSS, because that's genuinely all that's left standing by the time it renders.
The technique: hidden inputs and sibling combinators
The mechanism is the CSS :checked pseudo-class, applied to real HTML form controls:
- A hidden
<input type="radio">or<input type="checkbox">tracks one piece of state — which carousel slide is active, whether an accordion panel is open, which quiz answer was picked. - A visible
<label for="...">wraps whatever the recipient should be able to click — a "Next" arrow, an accordion header, a poll option — and toggles the input's checked state on click, with zero script involved; that's native<label>/<input>browser behavior. - A CSS sibling combinator (
:checked ~ .panel,:checked + .content) styles other elements based on that input's checked state — showing a slide, expanding a panel, revealing a "you picked B" message.
Stack enough of these — one input per state, one combinator rule per resulting style change — and the result reads as a genuinely stateful interface, built entirely from markup a client's <script>-stripping pass never touches because there's no script to strip.
Real-world support: a client-by-client breakdown
Per caniemail.com's tested client panel:
| Support level | Clients | | --- | --- | | Full support | Gmail (all platforms, since March 2020), Apple Mail (macOS 12.4+ / iOS 13.3+), Yahoo Mail, ProtonMail | | Partial support | Outlook.com, New Outlook, and mobile Outlook ("only supported on type selectors"); Samsung Email (Android 7.0+) | | No support | Classic Windows Outlook (2007–2019); Orange and SFR webmail (strip input elements outright) |
That's a materially different number from the ~91%+ real-world reach The 2026 State of Email Client Rendering reports for kinetic CSS generally — caniemail's figure counts clients equally regardless of how many recipients actually use each one, where the reach number weights by real share of tracked opens. Classic Windows Outlook fails this technique entirely, but it's also a shrinking minority of a market-share bucket Apple Mail alone already dwarfs — which is why weighting by actual usage, not by client count, is the number that should drive a design decision.
What happens where :checked isn't honored
In a client that doesn't support :checked at all, the hidden inputs and extra markup simply render inert — no error, no broken layout, just no interaction. The block falls back to whatever its default markup order shows: the first carousel slide, a closed accordion, a plain static list of quiz options. Designing that fallback deliberately, rather than letting an unsupported client show something half-broken, is the fallback engine's actual job — see How fallbacks work for the full three-tier model this technique sits inside.