Warum Websites in anderen Browsern still kaputtgehen

Der Fehlerbericht klingt vertraut: „Bei mir sieht die Seite kaputt aus." Die Entwicklerin öffnet die Seite, sieht — nichts. Alles an seinem Platz. Erst der Rückruf klärt die Lage: Der Kunde nutzt Safari auf dem iPhone, sie Chrome auf dem Desktop. Zwischen beiden liegen zwei Rendering-Engines, mehrere Bildschirmbreiten und eine Reihe stiller Unterschiede, von denen keiner jemals eine Fehlermeldung erzeugt hat.

Dass dieselbe Website je nach Browser anders aussehen kann, ist kein Betriebsunfall, sondern Architektur. Im Kern jedes Browsers arbeitet eine Rendering-Engine, die HTML und CSS in Pixel übersetzt. Drei Familien teilen sich heute praktisch den gesamten Markt: Blink treibt Chrome, Edge und die meisten kleineren Chromium-Ableger an, Gecko den Firefox, WebKit den Safari — und auf dem iPhone rendern bis heute praktisch alle verbreiteten Browser mit WebKit, auch wenn Chrome oder Firefox auf dem Icon steht.

Diese Engines sind unabhängige Implementierungen derselben Web-Standards. Die Standards beschreiben, was eine CSS-Eigenschaft bewirken soll — aber sie lassen Spielräume, sie werden unterschiedlich schnell umgesetzt, und gelegentlich verstehen zwei Entwicklungsteams dieselbe Formulierung verschieden. Das Ergebnis sind drei Programme, die dasselbe Dokument lesen und zu leicht unterschiedlichen Bildern kommen. Meist sind die Unterschiede unsichtbar klein. Manchmal nicht.

Der entscheidende Punkt: Diese Unterschiede bleiben lautlos. CSS ist bewusst fehlertolerant entworfen. Eine Eigenschaft, die ein Browser nicht kennt, wird schlicht ignoriert — ohne Warnung, ohne Absturz, ohne Eintrag in irgendeinem Protokoll. Was bei der Einführung neuer Techniken ein Segen ist, weil alte Browser moderne Stylesheets nicht mit einem Totalausfall quittieren, wird im Alltag zur Falle: Die Seite bricht nicht, sie sieht nur falsch aus. Und niemand erfährt davon, solange niemand hinschaut.

Die typischen Bruchstellen lassen sich sortieren. Da sind zunächst junge CSS-Funktionen, die eine Engine schon beherrscht und eine andere noch nicht oder in Details anders. Da sind Auslegungsfragen des Layouts — wie Flexbox und Grid mit Mindestbreiten, Umbrüchen oder verschachtelten Containern umgehen, wo die Spezifikation Interpretationsspielraum lässt. Und da sind die Klassiker: Formularelemente wie Auswahlfelder, Checkboxen und Datumseingaben, die jeder Browser nach eigenem Geschmack zeichnet und die sich nur begrenzt umgestalten lassen.

Ein Beispiel aus der ersten Kategorie macht das Muster greifbar. Die CSS-Eigenschaft gap, die Abstände zwischen Elementen regelt, war für das Grid-Layout früh in allen Engines verfügbar — im Flexbox-Kontext unterstützte Safari sie jedoch deutlich später als Chrome und Firefox. Eine Navigation, deren Menüpunkte per Flexbox und gap auf Abstand gehalten wurden, sah in zwei Engines tadellos aus; in älteren Safari-Versionen klebten die Punkte aneinander. Keine Fehlermeldung, kein Absturz, technisch funktionierte alles — nur wirkte die Seite auf einem Teil der iPhones gedrungen und ungepflegt. Abhilfe schafft in solchen Fällen eine Rückfalllösung mit klassischen Außenabständen; aber dazu muss man erst einmal wissen, dass der Unterschied existiert. Genau das ist bei stillen Brüchen die eigentliche Hürde: Sie stehen in keiner Fehlerliste. Sie stehen nur im Bild.

Dazu kommen Unterschiede, die gar nicht im Stylesheet stehen. Schriften werden auf jedem Betriebssystem anders gerendert und fallen unterschiedlich breit aus; eine Überschrift, die in einer Umgebung einzeilig bleibt, umbricht in der anderen und schiebt alles darunter nach unten. Scrollbalken nehmen je nach System Platz vom Inhalt weg oder legen sich darüber — und verändern damit die verfügbare Breite. Viewport-Einheiten verhalten sich auf Mobilgeräten unterschiedlich, je nachdem, wie der Browser ein- und ausblendende Adressleisten verrechnet.

Die zweite große Quelle stiller Brüche sind Bildschirmbreiten. Responsive Design definiert Umschaltpunkte — Breakpoints —, an denen sich das Layout umbaut: Die Navigation klappt zum Menü-Symbol zusammen, Spalten stapeln sich übereinander, Abstände schrumpfen. Getestet wird erfahrungsgemäß an den Standardbreiten der gängigen Geräte. Kaputt geht es dazwischen: bei ungewöhnlichen Fenstergrößen, auf Tablets im Querformat, bei halbierten Fenstern auf breiten Desktop-Monitoren.

Deutschsprachige Seiten trifft eine Eigenheit besonders hart: lange Komposita. Wo im Englischen drei kurze Wörter stehen, steht im Deutschen die „Datenschutzgrundverordnung" — ein Wort, das sich weigert umzubrechen, aus seinem Container ragt oder eine Navigation sprengt, sobald der Platz knapp wird. Übersetzte Oberflächen, die im englischen Original tadellos aussahen, gehören deshalb zu den verlässlichsten Kandidaten für Umbruch-Probleme.

Selbst eine Seite, die heute überall korrekt aussieht, bleibt das übrigens nicht von allein. Browser aktualisieren sich in kurzen Rhythmen selbst, Rendering-Engines ändern Details ihres Verhaltens — und die Website verändert ihr Aussehen, ohne dass irgendjemand etwas deployt hätte. Der sorgfältige Test zum Launch ist deshalb eine Momentaufnahme, kein Dauerzustand. Dasselbe gilt in die andere Richtung: Jedes CMS-Update, jedes neue Plugin, jede Textänderung kann Verschiebungen auslösen.

Hinter all dem steckt ein psychologisches Grundproblem, das jeder aus dem Entwicklungsalltag kennt: „Works on my machine." Wer eine Seite baut, sieht sie hundertfach im eigenen Browser auf dem eigenen Monitor — und hält diesen Anblick unbewusst für die Wahrheit. Die Besucherinnen und Besucher verteilen sich jedoch über Engines, Geräteklassen und Fenstergrößen, und keine davon meldet sich von selbst, wenn etwas verrutscht. Die wenigsten Menschen schreiben eine E-Mail, wenn ein Menü überlappt. Sie gehen einfach.

Umso wertvoller ist der seltene Fall, dass sich doch jemand meldet — vorausgesetzt, die Meldung wird methodisch abgearbeitet. Ein bewährtes Vorgehen hat vier Schritte. Erstens die Umgebung erfragen: welcher Browser, welches Gerät, welche ungefähre Fensterbreite? Ohne diese Angaben ist jede Suche Raten. Zweitens in der passenden Engine reproduzieren, nicht in einer Simulation — zur Not über einen Screenshot-Dienst, wenn gerade kein Gerät mit der richtigen Engine greifbar ist; wie ein solcher Prüflauf abläuft, beschreibt ScanU Schritt für Schritt. Drittens eingrenzen, welcher Mechanismus betroffen ist: Bricht das Layout an einem Umschaltpunkt, fehlt eine CSS-Funktion, fällt eine Schrift breiter aus? Die Antwort bestimmt die Reparatur — Breakpoint-Probleme löst das eigene Stylesheet, fehlende Funktionen brauchen eine Rückfalllösung, Schriftprobleme oft nur großzügigere Container. Und viertens, der Schritt, der am häufigsten entfällt: nach der Korrektur alle Engines erneut ansehen. Wer nur die gemeldete Stelle prüft, übersieht leicht, dass die Reparatur an anderer Stelle etwas verschoben hat.

Naheliegend wäre an dieser Stelle der Einwand, die Entwicklerwerkzeuge der Browser hätten das Problem längst gelöst: Jeder moderne Browser bringt einen Geräte-Modus mit, der Bildschirmgrößen von Telefonen und Tablets simuliert. Der Einwand übersieht, was dieser Modus tatsächlich tut. Wer in Chrome die iPhone-Ansicht wählt, bekommt ein schmales Fenster mit angepasster Auflösung und mobiler Kennung — gerendert wird aber weiterhin mit Blink, der Engine von Chrome. Die WebKit-Eigenheiten des echten iPhone-Browsers zeigt diese Simulation nicht, ebenso wenig die Gecko-Eigenheiten des Firefox. Für die Arbeit an Breakpoints ist der Geräte-Modus ein ausgezeichnetes Werkzeug; als Beleg für Browser-Kompatibilität taugt er nicht. Eine Engine lässt sich nicht simulieren, nur wechseln.

Wie findet man Brüche, die sich nicht melden? Der traditionelle Weg ist Handarbeit: ein Schrank voller Testgeräte oder eine Browserliste, die jemand nach jeder Änderung durchklickt. Das funktioniert, skaliert aber schlecht — schon drei Browser mal drei Geräteklassen ergeben neun Ansichten pro Seite, und die Sorgfalt sinkt erfahrungsgemäß mit jeder Wiederholung. Der systematischere Weg sind Screenshot-Dienste, die diese Sichtprüfung parallelisieren. ScanU etwa erstellt nach Eingabe einer URL in rund 30 Sekunden Screenshots in Chrome, Firefox und Safari, jeweils in Mobil-, Tablet- und Desktop-Ansichten; welche Gerätekombinationen verfügbar sind, listet die Funktionsübersicht von ScanU. Statt neun Fenster nacheinander zu öffnen, sieht man ein Raster von Bildern — und Ausreißer springen ins Auge.

Richtig interessant wird es in der Wiederholung. Dienste dieser Art vergleichen den aktuellen Stand mit einem gespeicherten Referenzzustand und markieren Abweichungen im direkten Nebeneinander. So wird aus der vagen Frage „sieht die Seite überall gut aus?" die deutlich schärfere Frage „hat sich seit dem letzten geprüften Stand etwas verändert?" — eine Frage, die sich auch dann beantworten lässt, wenn niemand mehr im Kopf hat, wie die Seite vergangene Woche aussah.

Auch hier gehört Ehrlichkeit dazu: Screenshots zeigen Zustände, keine Abläufe. Was beim Überfahren mit der Maus passiert, ob ein Menü sauber aufklappt, wie sich die Seite beim Scrollen oder bei langsamer Verbindung verhält — all das bildet ein statisches Bild nicht ab. Ebenso wenig ersetzt ein gerendertes Browserfenster das Gefühl echter Hardware: Touch-Bedienung, die Leistung älterer Geräte, Eigenheiten einzelner Systemversionen. Vor einem wichtigen Launch bleibt der Griff zum echten Telefon eine gute Idee, und funktionale Tests ersetzt ein Screenshot ohnehin nicht.

Wie viel Aufwand dem Thema angemessen ist, muss dabei niemand pauschal entscheiden — die eigenen Zugriffsstatistiken geben die Richtung vor. Sie zeigen, über welche Browser, Geräteklassen und Bildschirmbreiten die tatsächlichen Besucherinnen und Besucher kommen, und damit, welche Kombinationen in der Prüfliste Vorrang verdienen. Zwei Einschränkungen gehören allerdings dazu. Erstens misst die Statistik nur, wer kommt — nicht, wer wegen einer kaputten Ansicht gar nicht erst bleibt; eine schwach vertretene Engine kann also auch Folge eines Problems sein, nicht nur Zeichen geringer Relevanz. Zweitens unterscheiden sich die Anteile je nach Zielgruppe und Nutzungssituation erheblich: Ein Angebot, das abends auf dem Sofa gelesen wird, hat eine andere Geräteverteilung als ein Fachportal für den Büroalltag. Die eigene Prüfliste sollte deshalb den eigenen Zahlen folgen, nicht allgemeinen Marktübersichten.

Für den Alltag genügt oft eine einfache Routine: nach jeder Änderung an Styles oder Templates die wichtigsten Seiten über alle drei Engine-Familien prüfen; nach größeren Browser-Releases einmal den Bestand kontrollieren; bei Redesigns bewusst auch die Zwischenbreiten ansehen, nicht nur die Standardformate. Wer den Aufwand scheut, beginnt klein — die deutsche Seite von ScanU führt in den Dienst ein, dessen kostenlose Stufe mit einem Projekt und 500 Credits im Monat für erste Gehversuche reicht.

Der Kern des Problems bleibt dabei bestehen, und das ist vielleicht die eigentliche Erkenntnis: Browser werden auch künftig unabhängige Programme mit eigenen Engines sein, Standards werden weiter Spielräume lassen, und CSS wird weiter schweigen, statt zu warnen. Stille Brüche sind kein Zeichen schlampiger Arbeit, sondern eine Systemeigenschaft des Webs. Der Umgang damit ist deshalb vor allem eine Frage der Sichtbarkeit: Wer die eigene Seite regelmäßig mit den Augen aller drei Engines betrachtet — egal mit welchem Werkzeug —, nimmt dem Schweigen seine Wirkung.