Why Safari 27 Ships 525 Fixes: Notes From the WebKit Lab
The most revealing thing the Safari team said at WWDC 2026 was not about a feature. Across an hour in the Safari and Web Technologies group lab, the WebKit engineers kept circling one question: how does a browser team decide what to build, and why does it so often look slow from the outside? The answer they kept returning to, paraphrased from the lab, was that they genuinely do care, backed by a number you can check. Safari 27 ships 58 new features and 525 fixes, which WebKit calls “the largest pile of fixes in any Safari release in recent memory.”1 This post is about the reasoning underneath that number, drawn from the lab and grounded in WebKit’s own release notes.
The WWDC 2026 Safari & Web Technologies Group Lab.
TL;DR
- Safari 27 ships 58 new features and 525 fixes, the largest fix count in any Safari release.1 The lab framed this year as a paper-cut campaign: chase the small correctness bugs that make the platform trustworthy, not just the headline features.
- The clearest example is a rewrite of the JavaScript module loader. WebKit’s notes describe fixing “multiple top-level await correctness bugs with a rewrite of the ES module loader for standards compliance,” replacing an implementation based on an abandoned 2016 proposal that predated top-level await entirely.1
- The lab used the
:has()selector as its case study in how standards actually unstick: a feature engineers called impossible for years, until Igalia’s engineering made it fast enough, and it now ships in every major engine.23 - The form-control story matured:
appearance: base-selectclears native<select>styling so you start from a clean slate, with the broader “style every form control” direction still an unsettled spec the panel openly disagreed about.12 - WebKit and JavaScriptCore run on every Apple OS, including watchOS, and SwiftUI now has a first-class
WebView, so “the web engine” is closer to a system service than a single app.24
The number, and what it means
WebKit’s framing of Safari 27 is unusually quantitative. Past the new features, the release carries 525 fixes, “the largest pile of fixes in any Safari release.”1 In the lab, the team connected that number to a posture rather than a milestone: the paraphrased sentiment was that web developers sometimes read a browser’s choices as not caring about their daily experience, and the team’s answer was the opposite, that there is no advantage in making the web worse in Safari.2 You do not have to take the sentiment on faith, because the fix count is the evidence, and the lab’s own description of the release notes was that they go on long enough to scroll through for a while.2
The single best illustration is a piece of plumbing most developers never see. WebKit rewrote the JavaScript module loader. The release notes are specific: the team “fixed multiple top-level await correctness bugs with a rewrite of the ES module loader for standards compliance,” because the prior implementation was “based on an abandoned 2016 WHATWG Loader proposal that predated top-level await entirely” and could let imports access exports before they were fully initialized.1 Rewriting a module loader to fix a class of await ordering bugs is enormous effort for something that, done right, no one notices. That is the paper-cut campaign in one commit.
How a standard actually unsticks: the :has() story
The lab’s most useful narrative was about the CSS :has() selector, the long-wished-for parent selector. The paraphrased version from the panel: browser engineers said no for the better part of two decades, on the grounds that the chips were not fast enough to evaluate it without wrecking page performance, until the work to make it viable finally happened and it shipped across browsers.2 The verifiable spine under that story is real. WebKit shipped :has() in Safari 15.4, Chromium followed in Chrome 105 with engineering led by the open-source consultancy Igalia, and Firefox completed the set in version 121, so the selector that was “impossible” for years now works in every major engine.3
The lab tied this to a design principle worth knowing by name. The HTML project’s “priority of constituencies” ranks whose needs win when they conflict: users over authors, authors over implementors, implementors over specifiers, and all of them over theoretical purity.5 It is the rule that explains why a browser will carry an ugly compatibility workaround forever rather than break a site, and why a feature that helps authors can still wait years if implementing it would hurt users through performance. :has() is the rule resolving in slow motion: useful to authors, blocked on the user-cost of making it fast, shipped only once that cost came down.
The form-control project, and a disagreement in public
The most-requested CSS capability of the last decade is finally arriving: styling native form controls without rebuilding them from <div>s. Safari 27 ships appearance: base-select, which, in WebKit’s words, lets you “clear the native styling and start with a clean palette,” then layer your own CSS while keeping the control’s real semantics, keyboard handling, and accessibility.1 It pairs with ::picker(select), ::picker-icon, ::checkmark, and a <selectedcontent> element, the customizable-select surface covered in styling the real select element.
What the lab added was the honesty about how unfinished the broader vision is. Extending appearance: base to every form control is a stated direction, not a shipped spec, and the panel disagreed with itself on camera about the hardest question: what the unstyled baseline should even look like. Paraphrasing the exchange, one position was that an unstyled control should look like a plain modern control; the rebuttal was that “modern” is a moving fashion target and not a thing a spec can pin down, so the baseline should inherit as much as possible from the page and otherwise hold as little opinion as possible.2 The engineering constraint they agreed on is the genuinely hard part: the feature only works if the default rendering and the DOM structure are identical across browsers, because authors will style against both.2 That is why a 30-year-old problem is still a work in progress rather than a checkbox.
The web engine is a system service
A useful reframing from the lab: WebKit is much more than Safari. WebKit and JavaScriptCore ship on every Apple operating system, including watchOS, which has no browser at all, and any app that runs JavaScript leans on JavaScriptCore.2 WebKit’s own WWDC material makes the same point, describing app interfaces “powered by the HTML, CSS, and JavaScript that’s rendered by WebKit and JavaScriptCore, the same engines inside Safari,” across the platforms.1 The practical upshot for developers landed in 2025, when SwiftUI gained a native WebView and a WebPage model, making WebKit a first-class SwiftUI view instead of a WKWebView wrapped in UIViewRepresentable.4 When the web engine is this deep in the OS, “should this be native or web” stops being a binary.
What WebKit is shipping first, and building next
Two smaller threads are worth a developer’s attention. First, Safari continues to ship CSS features ahead of other engines: hanging-punctuation has been Safari-only for years, the CSS filter() function (distinct from the widely supported filter property) remains WebKit-only, and Safari recently shipped the random() function, with a companion random-item() for choosing among discrete values defined in the CSS Values draft.67 The “Safari is behind” reflex misses how often it is first.
Second, the web-extensions story is consolidating. The cross-browser WebExtensions effort is moving from a multi-year community group toward a formal W3C Working Group, with a 2025 draft charter aimed at a real interoperability spec.8 And Apple announced a consumer-facing twist at the WWDC 2026 keynote: “Describe an Extension,” which uses Apple Intelligence to generate and install a custom Safari extension from a plain-language description, no Xcode and no App Store round-trip.9 Treat that as a keynote announcement rather than a developer API, but the direction is clear: the extension surface is widening at both the standards layer and the end-user layer at once.
What to take from it
The lab is a window into a tradeoff most feature coverage skips. A browser team can chase headline features or chase correctness, and WebKit spent this release visibly choosing the second: 525 fixes, a module loader rewritten for a class of await bugs, a parent selector that waited two decades for the hardware to catch up. The lesson for anyone building on the platform is to read the release notes, not the keynote, when you want to know what actually got better. The features are in customizable select, CSS Grid Lanes, and the HTML model element; the reasoning behind the pace is in the lab.
FAQ
How many fixes are in Safari 27?
525 fixes alongside 58 new features, which WebKit describes as the largest fix count in any Safari release.1 The lab framed the year around correctness and “paper cuts” rather than headline features.
What is the module-loader rewrite?
WebKit rewrote Safari’s ES module loader for standards compliance, fixing multiple top-level await correctness bugs. The prior implementation was based on an abandoned 2016 WHATWG Loader proposal that predated top-level await, and could let imports access exports before they were fully initialized.1
Is appearance: base shipping?
appearance: base-select ships in Safari 27 for the <select> element, clearing native styling so you can apply your own CSS while keeping the control’s semantics.1 Extending appearance: base to all form controls is a stated direction but an unsettled spec, and the lab panel openly disagreed about what the unstyled default should look like.2
Did Apple really add AI-generated Safari extensions?
Yes. Apple announced “Describe an Extension” at the WWDC 2026 keynote: it uses Apple Intelligence to generate and install a custom Safari extension from a natural-language description, without Xcode or the App Store.9 It is a consumer feature, not a developer API.
The Safari feature posts cover the what: styling the real <select>, CSS Grid Lanes for native masonry, and the HTML <model> element. This one covers the why behind the pace. The full series hub is the Apple Ecosystem Series.
References
-
WebKit, News from WWDC26: WebKit in Safari 27 beta. Source for the 58 new features and 525 fixes (“the largest pile of fixes in any Safari release”), the ES module loader rewrite (“Fixed multiple top-level await correctness bugs with a rewrite of the ES module loader for standards compliance,” replacing an implementation “based on an abandoned 2016 WHATWG Loader proposal that predated top-level await entirely”), the
appearance: base-selectdescription (“clear the native styling and start with a clean palette”) with::picker(select)/::picker-icon/::checkmark/<selectedcontent>, and the framing of WebKit and JavaScriptCore as the engines behind app interfaces across Apple platforms. ↩↩↩↩↩↩↩↩↩↩↩ -
Apple, WWDC 2026 session 8015, Safari and Web Technologies Group Lab. Paraphrased from a locally transcribed recording; Apple publishes no official captions for the labs, so the wording here is a paraphrase, not a quotation, and exact phrasing is unverified. Source for the team’s caring-about-the-platform framing tied to the length of the release notes, the
:has()narrative that engineers resisted it for roughly two decades on performance grounds, the live disagreement over the unstyledappearance: basebaseline (modern-control vs inherit-from-page) and the cross-browser identical-rendering-and-DOM-structure constraint, and the point that WebKit/JavaScriptCore run on every Apple OS including watchOS. ↩↩↩↩↩↩↩↩↩↩ -
WebKit, Using :has() as a CSS Parent Selector and much more, and the cross-engine shipping record: Safari 15.4, Chrome 105 (engineering led by Igalia), Firefox 121. Source for
:has()shipping in all major browser engines after years of being considered infeasible. ↩↩ -
Apple, WebKit for SwiftUI and WWDC 2025 session 231, Meet WebKit for SwiftUI. Source for SwiftUI’s native
WebViewandWebPagemodel introduced in the 2025 releases, making WebKit a first-class SwiftUI view. ↩↩ -
W3C, HTML Design Principles: Priority of Constituencies. Source for the ordering “users over authors over implementors over specifiers over theoretical purity.” ↩
-
MDN / caniuse,
hanging-punctuationand the CSSfilter()function. Source for both being supported in Safari/WebKit and not in Chrome or Firefox at time of writing (thefilter()function is distinct from the widely supportedfilterproperty). ↩ -
W3C, CSS Values and Units Module Level 5, which defines
random()andrandom-item(). Safari has shipped therandom()function;random-item()selects among discrete keyword or property values. ↩ -
W3C, WebExtensions Community Group and the 2025 draft WebExtensions Working Group charter. Source for the cross-browser WebExtensions effort moving from a community group toward a formal Working Group. ↩
-
Apple announced “Describe an Extension” at the WWDC 2026 keynote, generating and installing a custom Safari extension from a natural-language description via Apple Intelligence, without Xcode or the App Store. Reported by MacRumors, June 8, 2026. Described here as a keynote announcement and consumer feature, not a developer API. ↩↩
