Eine Verschwörung zur Tötung von IE6

Avatar of Robin Rendle
Robin Rendle am

DigitalOcean bietet Cloud-Produkte für jede Phase Ihrer Reise. Starten Sie mit 200 $ kostenlosem Guthaben!

Chris Zacharias veröffentlichte einige Notizen darüber, warum das Team von YouTube im Jahr 2009 ein Banner hinzufügte, das die Benutzer aufforderte, von IE6 auf einen moderneren Browser zu wechseln.

Die bittersüße Folge von YouTubes unglaublichem Wachstum ist, dass so viele Geschichten unter all den Schichten neuer Farbe verloren gehen werden. Deshalb wollte ich die Geschichte erzählen, wie vor zehn Jahren ein kleines Team von Webentwicklern innerhalb von YouTube eine Verschwörung schwor, um IE6 zu eliminieren, und damit durchkam.

Ich erinnere mich nicht mehr an das genaue auslösende Ereignis, das dazu führte, dass unser Webentwicklerteam beim Mittagessen in der YouTube-Kantine Pläne zur Eliminierung von IE6 schmiedete. Vielleicht war es das Mal, als ich ein CSS-Stylesheet herausbrachte, das einen Attributselektor auf einem semi-unterstützten HTML-Element enthielt. Jeder vernünftige Webentwickler würde erwarten, dass dies von Browsern, die nicht dazu in der Lage sind, ignoriert wird. Dies war bei älteren IE-Versionen nicht der Fall. Unter sehr spezifischen Bedingungen würde ein Attributselektor auf einem nicht unterstützten HTML-Element in IE eine interne Rekursion hervorrufen, die im besten Fall zum Absturz des Browsers und im schlimmsten Fall zu einem Blue Screen of Death führen würde.

Hier gibt es viel Interessantes zu bedenken. IE6 war bekanntermaßen schwierig für Entwickler und führte dazu, dass Teams viel Zeit mit der Behebung von spielunterbrechenden Fehlern für das verbrachten, was oft nur einen winzigen Bruchteil ihres gesamten Website-Traffics ausmachte. Es ist jedoch wichtig zu beachten, dass, sobald man eine solche Entscheidung trifft, wo hört man auf? Es wird plötzlich einfacher, eine reine Chrome-Website zu erstellen, grundlegende Barrierefreiheitsprinzipien zu ignorieren, semantisches Markup zu ignorieren und eine Website zu erstellen, die für sich selbst optimiert ist. Das führt uns zu heikleren Themen wie Browserdiversität und proprietären Ressourcen, die im Widerspruch zu einem offenen, inklusiven Web zu stehen scheinen.

Ich erinnere mich hier an Jeremy Keiths Buch, Resilient Web Design, in dem er schreibt

Wenn eine Website mit progressiver Verbesserung erstellt wird, ist es in Ordnung, wenn eine bestimmte Funktion nicht unterstützt wird oder nicht geladen wird: Ajax, Geolokalisierung, was auch immer. Solange die Kernfunktionalität weiterhin verfügbar ist, müssen Webdesigner nicht übermäßigen Aufwand betreiben, um die Unterstützung für neuere Funktionen in älteren Browsern zu erzwingen.

Und Jeremy zitiert Mat Marquis, der zufällig am responsiven Redesign von The Boston Globe mitarbeitete, wo er argumentierte, dass

Viele coole Features auf der Boston Globe funktionieren nicht, wenn JS kaputt geht; „Nachrichten lesen“ gehört nicht dazu.

Vielleicht gibt es hier einen Mittelweg; vielleicht auch nicht. Aber ich finde Mats und Jeremys Ansatz inspirierender und besser für die allgemeine Gesundheit des Webs.

Direkter Link →