Wie Fallbacks funktionieren

Die Fallback-Engine ist das Herzstück von MailInApp. Sie existiert, weil sich E-Mail-Clients über so gut wie alles uneinig sind: manche rendern modernes CSS, manche entfernen <style>-Tags vollständig, und das klassische Outlook rendert E-Mails weiterhin mit der Engine von Microsoft Word. Statt für den kleinsten gemeinsamen Nenner zu gestalten, gestalten Sie einmal — und die Engine kompiliert jeden Block in drei Stufen.

Die drei Stufen

Stufe 1 — Kinetisch

Vollständige CSS-Interaktivität: Karussells, die gleiten, Akkordeons, die sich ausklappen, Reveals, die animieren. Kinetisches Markup basiert auf CSS-Zustandsautomaten — versteckte Checkboxen und Radio-Eingaben, deren :checked-Zustand bestimmt, was sichtbar ist —, denn das ist die Interaktivität, die E-Mail-Clients tatsächlich unterstützen. Es wird niemals JavaScript verwendet; jeder E-Mail-Client entfernt es.

Kinetisches Rendering erreicht Gmail (Web und mobile Apps), Apple Mail, Yahoo Mail und Samsung Mail — die große Mehrheit der privaten Postfächer.

Stufe 2 — Statisch

Manche Clients entfernen <style>-Blöcke vollständig (und Gmail entfernt sie aus gekürzten Nachrichten). Für sie fällt jeder Block auf sauberen, gestapelten Inhalt mit einem Call-to-Action-Link zurück — um abzustimmen, die Galerie zu öffnen, das Formular abzusenden —, der auf die gehostete Live-Ansicht verweist. Einfache Links funktionieren in 100 % der E-Mail-Clients, was diese Stufe universell macht.

Stufe 3 — Outlook

Das klassische Outlook für Windows rendert mit Word, das weder kinetisches CSS noch die meisten modernen Layouts unterstützt. Die Engine erzeugt für jeden Block eine dedizierte, tabellenbasierte Version innerhalb von Outlook-Conditional-Comments — Markup, das nur die Word-Engine sieht. Empfänger mit klassischem Outlook erhalten eine saubere, bewusst gestaltete E-Mail, niemals eine kaputte.

Eine E-Mail, jedes Postfach

Alle drei Stufen werden in derselben HTML-Datei ausgeliefert. Welche Stufe ein Empfänger sieht, entscheiden die eigenen Rendering-Regeln seines Clients, nicht eine anfällige Client-Erkennung:

• Clients, die kinetisches CSS unterstützen, rendern Stufe 1 und blenden die statische Variante aus;
• Clients, die Styles entfernen, rendern von Natur aus Stufe 2;
• die Word-Engine sieht nur Stufe 3, über Conditional Comments.

Interaktion folgt derselben Philosophie

Datensammelnde Blöcke (Abstimmungen, Bewertungen, Formulare) setzen standardmäßig auf linkbasierte Interaktion — jede Option ist ein einfacher Link, der die Antwort erfasst —, weil Links das einzige Grundelement sind, das überall funktioniert. In-E-Mail-Formularübermittlung ist als progressive Erweiterung in Clients aufgesetzt, die sie unterstützen. Details unter Interaktionen & Analysen.

Was die Engine bewusst nicht tut

Ein Teil der Aufgabe der Engine besteht darin, Nein zu sagen. Techniken mit schlechter oder uneinheitlicher Client-Unterstützung — JavaScript, eingebettetes Video, <details>-Elemente, CSS-Variablen — werden nie eingesetzt, egal wie verlockend die Demo aussehen würde. Wenn eine Technik nicht sauber degradieren kann, wird sie nicht ausgeliefert. Das vollständige Unterstützungsbild finden Sie unter E-Mail-Client-Unterstützung.

AMP for Email erhält einen eigenen, expliziten Abschnitt, nicht nur eine Erwähnung in dieser Liste: Es ist eine bewusste Abwägung, kein fehlendes Feature. Siehe Warum nicht AMP for Email?