Warum Safari 27 mit 525 Fehlerbehebungen erscheint: Notizen aus dem WebKit-Lab

Das Aufschlussreichste, was das Safari-Team auf der WWDC 2026 sagte, betraf keine einzelne Funktion. Über eine Stunde hinweg kreisten die WebKit-Ingenieure im Lab der Safari and Web Technologies Group immer wieder um eine Frage: Wie entscheidet ein Browser-Team, was es baut, und warum wirkt das von außen so oft langsam? Die Antwort, zu der sie immer wieder zurückkehrten, sinngemäß aus dem Lab wiedergegeben, lautete, dass es ihnen wirklich am Herzen liegt, gestützt auf eine überprüfbare Zahl. Safari 27 erscheint mit 58 neuen Funktionen und 525 Fehlerbehebungen, was WebKit als „den größten Stapel an Fehlerbehebungen in irgendeinem Safari-Release der jüngeren Erinnerung” bezeichnet.¹ In diesem Beitrag geht es um die Überlegungen hinter dieser Zahl, geschöpft aus dem Lab und verankert in WebKits eigenen Release Notes.

Das WWDC-2026-Safari & Web Technologies Group Lab.

Kurzfassung

• Safari 27 erscheint mit 58 neuen Funktionen und 525 Fehlerbehebungen, der größten Zahl an Fehlerbehebungen in irgendeinem Safari-Release.¹ Das Lab rahmte dieses Jahr als Feldzug gegen die kleinen Ärgernisse: die kleinen Korrektheitsfehler jagen, die die Plattform vertrauenswürdig machen, nicht nur die schlagzeilenträchtigen Funktionen.
• Das deutlichste Beispiel ist ein Umbau des JavaScript-Modul-Loaders. WebKits Notizen beschreiben die Behebung „mehrerer Korrektheitsfehler bei top-level await durch einen Umbau des ES module loaders zur Standardkonformität” und ersetzen damit eine Implementierung, die auf einem aufgegebenen Vorschlag von 2016 beruhte, der top-level await noch gar nicht kannte.¹
• Das Lab nutzte den :has()-Selektor als Fallstudie dafür, wie sich Standards tatsächlich lösen: eine Funktion, die Ingenieure jahrelang für unmöglich hielten, bis Igalias Arbeit sie schnell genug machte, und die nun in jeder großen Engine erscheint.²³
• Die Geschichte rund um die Formularsteuerelemente reifte heran: appearance: base-select räumt das native <select>-Styling beiseite, sodass Sie von einer sauberen Grundlage aus starten, während die umfassendere Richtung „jedes Formularsteuerelement stylen” weiterhin eine ungeklärte Spezifikation ist, über die das Panel offen uneins war.¹²
• WebKit und JavaScriptCore laufen auf jedem Apple-Betriebssystem, einschließlich watchOS, und SwiftUI verfügt nun über eine erstklassige WebView, sodass „die Web-Engine” eher einem Systemdienst als einer einzelnen App gleicht.²⁴

Die Zahl und ihre Bedeutung

WebKits Rahmung von Safari 27 ist ungewöhnlich quantitativ. Über die neuen Funktionen hinaus trägt das Release 525 Fehlerbehebungen, „den größten Stapel an Fehlerbehebungen in irgendeinem Safari-Release”.¹ Im Lab verknüpfte das Team diese Zahl mit einer Haltung statt mit einem Meilenstein: Sinngemäß war die Stimmung, dass Webentwickler die Entscheidungen eines Browsers manchmal so lesen, als kümmere er sich nicht um ihren Arbeitsalltag, und die Antwort des Teams war das Gegenteil, nämlich dass es keinen Vorteil darin gibt, das Web in Safari schlechter zu machen.² Sie müssen diese Stimmung nicht auf gut Glauben hinnehmen, denn die Zahl der Fehlerbehebungen ist der Beweis, und die eigene Beschreibung der Release Notes durch das Lab lautete, dass man eine Weile durch sie scrollen muss.²

Die mit Abstand beste Veranschaulichung ist ein Stück Maschinerie, das die meisten Entwickler nie zu Gesicht bekommen. WebKit hat den JavaScript-Modul-Loader umgebaut. Die Release Notes sind konkret: Das Team „behob mehrere Korrektheitsfehler bei top-level await durch einen Umbau des ES module loaders zur Standardkonformität”, weil die vorherige Implementierung „auf einem aufgegebenen WHATWG-Loader-Vorschlag von 2016 beruhte, der top-level await noch gar nicht kannte”, und Importe auf Exporte zugreifen lassen konnte, bevor diese vollständig initialisiert waren.¹ Einen Modul-Loader umzubauen, um eine ganze Klasse von await-Reihenfolgefehlern zu beheben, ist ein enormer Aufwand für etwas, das niemand bemerkt, wenn es richtig gemacht wird. Das ist der Feldzug gegen die kleinen Ärgernisse in einem einzigen Commit.

Wie sich ein Standard tatsächlich löst: die :has()-Geschichte

Die nützlichste Erzählung des Labs drehte sich um den CSS-:has()-Selektor, den lang ersehnten Parent-Selektor. Die sinngemäße Fassung aus dem Panel: Browser-Ingenieure sagten gut zwei Jahrzehnte lang Nein, mit der Begründung, dass die Chips nicht schnell genug seien, um ihn auszuwerten, ohne die Seitenleistung zu ruinieren, bis die Arbeit, ihn praktikabel zu machen, schließlich getan war und er browserübergreifend erschien.² Das überprüfbare Rückgrat dieser Geschichte ist real. WebKit lieferte :has() in Safari 15.4 aus, Chromium folgte in Chrome 105 mit einer von der Open-Source-Beratung Igalia geleiteten Entwicklung, und Firefox vervollständigte das Bild in Version 121, sodass der jahrelang „unmögliche” Selektor nun in jeder großen Engine funktioniert.³

Das Lab knüpfte dies an ein Designprinzip, das man dem Namen nach kennen sollte. Die „priority of constituencies” des HTML-Projekts ordnet, wessen Bedürfnisse gewinnen, wenn sie in Konflikt geraten: Nutzer vor Autoren, Autoren vor Implementierern, Implementierer vor Spezifizierern, und sie alle vor theoretischer Reinheit.⁵ Es ist die Regel, die erklärt, warum ein Browser einen hässlichen Kompatibilitäts-Workaround für immer mitschleppt, statt eine Website zu brechen, und warum eine Funktion, die Autoren hilft, dennoch jahrelang warten kann, wenn ihre Implementierung Nutzer durch Leistungseinbußen schädigen würde. :has() ist diese Regel, die sich in Zeitlupe auflöst: nützlich für Autoren, blockiert durch die Nutzerkosten, sie schnell zu machen, ausgeliefert erst, als diese Kosten sanken.

Das Projekt der Formularsteuerelemente und ein Streit in aller Öffentlichkeit

Die meistgewünschte CSS-Fähigkeit des letzten Jahrzehnts kommt endlich: native Formularsteuerelemente stylen, ohne sie aus <div>s neu nachzubauen. Safari 27 erscheint mit appearance: base-select, was Ihnen in WebKits Worten erlaubt, „das native Styling zu entfernen und mit einer sauberen Palette zu starten”, um dann Ihr eigenes CSS darüberzulegen und dabei die echte Semantik, Tastaturbehandlung und Barrierefreiheit des Steuerelements zu erhalten.¹ Es geht einher mit ::picker(select), ::picker-icon, ::checkmark und einem <selectedcontent>-Element, der Customizable-Select-Oberfläche, die in das echte select-Element stylen behandelt wird.

Was das Lab hinzufügte, war die Ehrlichkeit darüber, wie unfertig die umfassendere Vision ist. appearance: base auf jedes Formularsteuerelement auszuweiten, ist eine erklärte Richtung, keine ausgelieferte Spezifikation, und das Panel war vor laufender Kamera mit sich selbst über die schwierigste Frage uneins: wie die ungestylte Grundlinie überhaupt aussehen sollte. Sinngemäß lautete eine Position, dass ein ungestyltes Steuerelement wie ein schlichtes modernes Steuerelement aussehen sollte; der Einwand war, dass „modern” ein bewegliches Modeziel ist und nichts, was eine Spezifikation festnageln kann, sodass die Grundlinie so viel wie möglich von der Seite erben und ansonsten so wenig Meinung wie möglich vertreten sollte.² Die technische Einschränkung, auf die sie sich einigten, ist der wirklich schwierige Teil: Die Funktion funktioniert nur, wenn das Standard-Rendering und die DOM-Struktur browserübergreifend identisch sind, weil Autoren gegen beide stylen werden.² Deshalb ist ein 30 Jahre altes Problem immer noch eine laufende Arbeit statt ein abgehaktes Kästchen.

Die Web-Engine ist ein Systemdienst

Eine nützliche Neurahmung aus dem Lab: WebKit ist weit mehr als Safari. WebKit und JavaScriptCore werden auf jedem Apple-Betriebssystem ausgeliefert, einschließlich watchOS, das überhaupt keinen Browser hat, und jede App, die JavaScript ausführt, stützt sich auf JavaScriptCore.² WebKits eigenes WWDC-Material trifft denselben Punkt und beschreibt App-Oberflächen, „angetrieben von dem HTML, CSS und JavaScript, das von WebKit und JavaScriptCore gerendert wird, denselben Engines im Inneren von Safari”, über die Plattformen hinweg.¹ Die praktische Konsequenz für Entwickler landete 2025, als SwiftUI eine native WebView und ein WebPage-Modell erhielt, womit WebKit zu einer erstklassigen SwiftUI-View wird statt einer in UIViewRepresentable gewickelten WKWebView.⁴ Wenn die Web-Engine so tief im Betriebssystem steckt, hört „sollte das nativ oder Web sein” auf, eine Entweder-oder-Frage zu sein.

Was WebKit zuerst ausliefert und als Nächstes baut

Zwei kleinere Stränge verdienen die Aufmerksamkeit eines Entwicklers. Erstens liefert Safari weiterhin CSS-Funktionen vor anderen Engines aus: hanging-punctuation ist seit Jahren Safari-exklusiv, die CSS-filter()-Funktion (zu unterscheiden von der breit unterstützten filter-Eigenschaft) bleibt WebKit-exklusiv, und Safari lieferte kürzlich die random()-Funktion aus, mit einem begleitenden random-item() zur Auswahl unter diskreten Werten, das im CSS-Values-Entwurf definiert ist.⁶⁷ Der Reflex „Safari hinkt hinterher” übersieht, wie oft es vorneweg geht.

Zweitens konsolidiert sich die Geschichte der Web-Erweiterungen. Das browserübergreifende WebExtensions-Vorhaben bewegt sich von einer mehrjährigen Community Group hin zu einer formalen W3C Working Group, mit einem Charterentwurf von 2025, der auf eine echte Interoperabilitätsspezifikation zielt.⁸ Und Apple kündigte auf der WWDC-2026-Keynote eine verbraucherorientierte Wendung an: „Describe an Extension”, das mit Apple Intelligence aus einer umgangssprachlichen Beschreibung eine maßgeschneiderte Safari-Erweiterung generiert und installiert, ohne Xcode und ohne den Umweg über den App Store.⁹ Behandeln Sie das als Keynote-Ankündigung statt als Entwickler-API, doch die Richtung ist klar: Die Erweiterungsoberfläche weitet sich zugleich auf der Standards-Ebene und auf der Endnutzer-Ebene aus.

Was man daraus mitnehmen sollte

Das Lab ist ein Fenster in einen Zielkonflikt, den die meiste Funktionsberichterstattung überspringt. Ein Browser-Team kann schlagzeilenträchtigen Funktionen nachjagen oder der Korrektheit nachjagen, und WebKit wählte in diesem Release sichtbar das Zweite: 525 Fehlerbehebungen, ein für eine Klasse von await-Fehlern umgebauter Modul-Loader, ein Parent-Selektor, der zwei Jahrzehnte darauf wartete, dass die Hardware aufholt. Die Lehre für jeden, der auf der Plattform aufbaut, lautet: Lesen Sie die Release Notes, nicht die Keynote, wenn Sie wissen wollen, was tatsächlich besser geworden ist. Die Funktionen finden sich in Customizable Select, CSS Grid Lanes und dem HTML-model-Element; die Begründung hinter dem Tempo liegt im Lab.

FAQ

Wie viele Fehlerbehebungen enthält Safari 27?

525 Fehlerbehebungen neben 58 neuen Funktionen, was WebKit als die größte Zahl an Fehlerbehebungen in irgendeinem Safari-Release beschreibt.¹ Das Lab rahmte das Jahr um Korrektheit und „kleine Ärgernisse” statt um schlagzeilenträchtige Funktionen.

Was ist der Umbau des Modul-Loaders?

WebKit baute Safaris ES module loader zur Standardkonformität um und behob dabei mehrere Korrektheitsfehler bei top-level await. Die vorherige Implementierung beruhte auf einem aufgegebenen WHATWG-Loader-Vorschlag von 2016, der top-level await noch gar nicht kannte, und konnte Importe auf Exporte zugreifen lassen, bevor diese vollständig initialisiert waren.¹

Erscheint appearance: base?

appearance: base-select erscheint in Safari 27 für das <select>-Element und räumt das native Styling beiseite, sodass Sie Ihr eigenes CSS anwenden können, während die Semantik des Steuerelements erhalten bleibt.¹ appearance: base auf alle Formularsteuerelemente auszuweiten, ist eine erklärte Richtung, aber eine ungeklärte Spezifikation, und das Lab-Panel war offen uneins darüber, wie der ungestylte Standard aussehen sollte.²

Hat Apple wirklich KI-generierte Safari-Erweiterungen hinzugefügt?

Ja. Apple kündigte „Describe an Extension” auf der WWDC-2026-Keynote an: Es nutzt Apple Intelligence, um aus einer natürlichsprachlichen Beschreibung eine maßgeschneiderte Safari-Erweiterung zu generieren und zu installieren, ohne Xcode oder den App Store.⁹ Es ist eine Verbraucherfunktion, keine Entwickler-API.

Die Safari-Funktionsbeiträge behandeln das Was: das echte <select> stylen, CSS Grid Lanes für natives Masonry und das HTML-<model>-Element. Dieser hier behandelt das Warum hinter dem Tempo. Der vollständige Knotenpunkt der Reihe ist die Apple Ecosystem Series.

References