How fallbacks work

The fallback engine is the heart of MailInApp. It exists because email clients disagree about everything: some render modern CSS, some strip <style> tags, and classic Outlook renders email with Microsoft Word's engine. Instead of designing for the lowest common denominator, you design once — and the engine compiles every block into three tiers.

The three tiers

Tier 1 — Kinetic

Full CSS interactivity: carousels that slide, accordions that expand, reveals that animate. Kinetic markup is built on CSS state machines — hidden checkboxes and radio inputs whose :checked state drives what's visible — because that's the interactivity email clients actually support. No JavaScript is ever used; every email client strips it.

Kinetic rendering reaches Gmail (web and mobile apps), Apple Mail, Yahoo Mail and Samsung Mail — the large majority of consumer inboxes.

Tier 2 — Static

Some clients strip <style> blocks entirely (and Gmail drops them from clipped messages). For them, every block collapses to clean, stacked content with a call-to-action link — to vote, to open the gallery, to submit the form — pointing at the hosted live view. Plain links work in 100% of email clients, which makes this tier universal.

Tier 3 — Outlook

Classic Outlook for Windows renders with Word, which supports neither kinetic CSS nor most modern layout. The engine emits a dedicated table-based version of each block inside Outlook conditional comments — markup only the Word engine sees. Recipients on classic Outlook get a clean, intentional email, never a broken one.

One email, every inbox

All three tiers ship inside the same HTML file. Which tier a recipient sees is decided by their client's own rendering rules, not by fragile client-detection:

• clients that support kinetic CSS render Tier 1 and hide the static variant;
• clients that strip styles naturally render Tier 2;
• the Word engine only sees Tier 3, via conditional comments.

Interaction follows the same philosophy

Data-collecting blocks (polls, ratings, forms) default to link-based interaction — each option is a plain link that records the response — because links are the one primitive that works everywhere. In-email form submission is layered on top as a progressive enhancement in clients that support it. Details in Interactions & analytics.

What the engine refuses to do

Part of the engine's job is saying no. Techniques with poor or inconsistent client support — JavaScript, embedded video, <details> elements, CSS variables — are not used, ever, no matter how tempting the demo would look. If a technique can't degrade gracefully, it doesn't ship. The full support picture is in Email client support.

AMP for Email gets its own explicit call-out, not just a mention in that list: it's a deliberate trade-off, not a missing feature. See Why not AMP for Email?