Pourquoi Safari 27 livre 525 correctifs : notes du labo WebKit

La chose la plus révélatrice que l’équipe Safari a dite à la WWDC 2026 ne concernait pas une fonctionnalité. Pendant une heure passée dans le labo du groupe Safari and Web Technologies, les ingénieurs WebKit n’ont cessé de tourner autour d’une même question : comment une équipe de navigateur décide-t-elle quoi construire, et pourquoi cela paraît-il si souvent lent vu de l’extérieur ? La réponse à laquelle ils revenaient sans cesse, paraphrasée depuis le labo, était qu’ils s’en soucient véritablement, appuyée par un chiffre que vous pouvez vérifier. Safari 27 livre 58 nouvelles fonctionnalités et 525 correctifs, ce que WebKit appelle « la plus grosse pile de correctifs de toutes les versions récentes de Safari ».¹ Cet article porte sur le raisonnement qui sous-tend ce chiffre, tiré du labo et ancré dans les notes de version de WebKit elles-mêmes.

Le Safari & Web Technologies Group Lab de la WWDC 2026.

En bref

• Safari 27 livre 58 nouvelles fonctionnalités et 525 correctifs, le plus grand nombre de correctifs de toutes les versions de Safari.¹ Le labo a présenté cette année comme une campagne contre les irritants : traquer les petits bugs de conformité qui rendent la plateforme digne de confiance, et pas seulement les fonctionnalités phares.
• L’exemple le plus net est une réécriture du chargeur de modules JavaScript. Les notes de WebKit décrivent la correction de « plusieurs bugs de conformité liés à top-level await grâce à une réécriture de l’ES module loader pour la conformité aux standards », remplaçant une implémentation fondée sur une proposition abandonnée de 2016 qui précédait entièrement top-level await.¹
• Le labo a utilisé le sélecteur :has() comme étude de cas sur la manière dont les standards se débloquent réellement : une fonctionnalité que les ingénieurs ont jugée impossible pendant des années, jusqu’à ce que le travail d’ingénierie d’Igalia la rende assez rapide, et qu’elle soit désormais livrée dans tous les grands moteurs.²³
• L’histoire des contrôles de formulaire a mûri : appearance: base-select efface le style natif de <select> pour partir d’une page blanche, tandis que l’orientation plus large « styler tous les contrôles de formulaire » demeure une spécification non figée sur laquelle le panel a ouvertement exprimé son désaccord.¹²
• WebKit et JavaScriptCore tournent sur tous les OS d’Apple, y compris watchOS, et SwiftUI dispose désormais d’une WebView de première classe, si bien que « le moteur web » est plus proche d’un service système que d’une simple application.²⁴

Le chiffre, et ce qu’il signifie

La manière dont WebKit présente Safari 27 est exceptionnellement quantitative. Au-delà des nouvelles fonctionnalités, la version embarque 525 correctifs, « la plus grosse pile de correctifs de toutes les versions de Safari ».¹ Dans le labo, l’équipe a relié ce chiffre à une posture plutôt qu’à un jalon : le sentiment paraphrasé était que les développeurs web interprètent parfois les choix d’un navigateur comme un désintérêt pour leur expérience quotidienne, et la réponse de l’équipe était l’inverse, à savoir qu’il n’y a aucun avantage à rendre le web pire dans Safari.² Vous n’avez pas à prendre ce sentiment pour argent comptant, car le nombre de correctifs en est la preuve, et la description que le labo a faite de ses propres notes de version est qu’elles sont assez longues pour qu’on les fasse défiler un bon moment.²

La meilleure illustration est une pièce de plomberie que la plupart des développeurs ne voient jamais. WebKit a réécrit le chargeur de modules JavaScript. Les notes de version sont précises : l’équipe a « corrigé plusieurs bugs de conformité liés à top-level await grâce à une réécriture de l’ES module loader pour la conformité aux standards », parce que l’implémentation précédente était « fondée sur une proposition WHATWG Loader abandonnée de 2016 qui précédait entièrement top-level await » et pouvait laisser des imports accéder à des exports avant qu’ils ne soient pleinement initialisés.¹ Réécrire un chargeur de modules pour corriger une classe de bugs d’ordonnancement de await représente un effort énorme pour quelque chose que, bien fait, personne ne remarque. Voilà la campagne contre les irritants résumée en un seul commit.

Comment un standard se débloque réellement : l’histoire de :has()

Le récit le plus utile du labo concernait le sélecteur CSS :has(), le sélecteur de parent tant attendu. La version paraphrasée du panel : les ingénieurs de navigateurs ont dit non pendant la plus grande partie de deux décennies, au motif que les puces n’étaient pas assez rapides pour l’évaluer sans ruiner les performances des pages, jusqu’à ce que le travail nécessaire pour le rendre viable aboutisse enfin et qu’il soit livré dans tous les navigateurs.² L’ossature vérifiable sous ce récit est bien réelle. WebKit a livré :has() dans Safari 15.4, Chromium a suivi dans Chrome 105 avec une ingénierie menée par le cabinet de conseil open source Igalia, et Firefox a complété le tableau dans la version 121, si bien que le sélecteur jugé « impossible » pendant des années fonctionne désormais dans tous les grands moteurs.³

Le labo a relié cela à un principe de conception qui mérite d’être connu par son nom. La « priorité des parties prenantes » du projet HTML hiérarchise les besoins qui l’emportent en cas de conflit : les utilisateurs avant les auteurs, les auteurs avant les implémenteurs, les implémenteurs avant les rédacteurs de spécifications, et tous avant la pureté théorique.⁵ C’est la règle qui explique pourquoi un navigateur conservera à jamais un vilain contournement de compatibilité plutôt que de casser un site, et pourquoi une fonctionnalité qui aide les auteurs peut tout de même attendre des années si sa mise en œuvre nuisait aux utilisateurs par ses performances. :has() est cette règle qui se résout au ralenti : utile aux auteurs, bloqué par le coût utilisateur de le rendre rapide, livré seulement une fois ce coût abaissé.

Le projet des contrôles de formulaire, et un désaccord en public

La capacité CSS la plus demandée de la dernière décennie arrive enfin : styler les contrôles de formulaire natifs sans les reconstruire à partir de <div>. Safari 27 livre appearance: base-select, qui, selon les mots de WebKit, vous permet d’« effacer le style natif et de partir d’une palette vierge », puis de superposer votre propre CSS tout en conservant la sémantique réelle du contrôle, la gestion du clavier et l’accessibilité.¹ Cela s’accompagne de ::picker(select), ::picker-icon, ::checkmark et d’un élément <selectedcontent>, la surface du select personnalisable abordée dans styler le vrai élément select.

Ce que le labo a ajouté, c’est l’honnêteté quant au caractère inachevé de la vision plus large. Étendre appearance: base à tous les contrôles de formulaire est une orientation annoncée, pas une spécification livrée, et le panel s’est contredit à l’écran sur la question la plus difficile : à quoi devrait même ressembler la base de référence non stylée. Pour paraphraser l’échange, une position soutenait qu’un contrôle non stylé devrait ressembler à un contrôle moderne ordinaire ; la réfutation était que « moderne » est une cible mouvante de la mode, pas une chose qu’une spécification peut figer, de sorte que la base de référence devrait hériter autant que possible de la page et, pour le reste, exprimer le moins d’opinion possible.² La contrainte d’ingénierie sur laquelle ils se sont accordés est la partie réellement difficile : la fonctionnalité ne marche que si le rendu par défaut et la structure du DOM sont identiques d’un navigateur à l’autre, parce que les auteurs styleront en se basant sur les deux.² Voilà pourquoi un problème vieux de 30 ans reste un chantier en cours plutôt qu’une case à cocher.

Le moteur web est un service système

Un recadrage utile issu du labo : WebKit est bien plus que Safari. WebKit et JavaScriptCore sont livrés sur tous les systèmes d’exploitation d’Apple, y compris watchOS, qui n’a aucun navigateur, et toute application qui exécute du JavaScript s’appuie sur JavaScriptCore.² Le propre matériel WWDC de WebKit fait la même remarque, décrivant des interfaces d’application « propulsées par le HTML, le CSS et le JavaScript rendus par WebKit et JavaScriptCore, les mêmes moteurs qui équipent Safari », à travers les plateformes.¹ La conséquence pratique pour les développeurs s’est concrétisée en 2025, lorsque SwiftUI a gagné une WebView native et un modèle WebPage, faisant de WebKit une vue SwiftUI de première classe plutôt qu’un WKWebView enveloppé dans un UIViewRepresentable.⁴ Quand le moteur web est aussi profondément ancré dans l’OS, « est-ce que ceci doit être natif ou web » cesse d’être binaire.

Ce que WebKit livre en premier, et construit ensuite

Deux fils plus modestes méritent l’attention d’un développeur. D’abord, Safari continue de livrer des fonctionnalités CSS en avance sur les autres moteurs : hanging-punctuation est resté exclusif à Safari pendant des années, la fonction CSS filter() (distincte de la propriété filter largement prise en charge) demeure réservée à WebKit, et Safari a récemment livré la fonction random(), avec une compagne random-item() pour choisir parmi des valeurs discrètes définies dans le brouillon CSS Values.⁶⁷ Le réflexe « Safari est en retard » passe à côté de la fréquence à laquelle il est en avance.

Ensuite, l’histoire des extensions web se consolide. L’effort multinavigateur WebExtensions passe d’un groupe communautaire pluriannuel à un Working Group formel du W3C, avec un projet de charte 2025 visant une véritable spécification d’interopérabilité.⁸ Et Apple a annoncé une nouveauté grand public lors du keynote de la WWDC 2026 : « Describe an Extension », qui utilise Apple Intelligence pour générer et installer une extension Safari sur mesure à partir d’une description en langage courant, sans Xcode ni aller-retour par l’App Store.⁹ Traitez cela comme une annonce de keynote plutôt que comme une API de développeur, mais l’orientation est claire : la surface des extensions s’élargit à la fois au niveau des standards et au niveau de l’utilisateur final.

Ce qu’il faut en retenir

Le labo est une fenêtre sur un arbitrage que la couverture des fonctionnalités escamote le plus souvent. Une équipe de navigateur peut courir après les fonctionnalités phares ou après la conformité, et WebKit a, dans cette version, visiblement choisi la seconde : 525 correctifs, un chargeur de modules réécrit pour une classe de bugs await, un sélecteur de parent qui a attendu deux décennies que le matériel rattrape son retard. La leçon pour quiconque construit sur la plateforme est de lire les notes de version, pas le keynote, quand vous voulez savoir ce qui s’est réellement amélioré. Les fonctionnalités sont dans le select personnalisable, CSS Grid Lanes et l’élément HTML model ; le raisonnement derrière le rythme est dans le labo.

FAQ

Combien de correctifs y a-t-il dans Safari 27 ?

525 correctifs aux côtés de 58 nouvelles fonctionnalités, ce que WebKit décrit comme le plus grand nombre de correctifs de toutes les versions de Safari.¹ Le labo a articulé l’année autour de la conformité et des « irritants » plutôt que des fonctionnalités phares.

Qu’est-ce que la réécriture du chargeur de modules ?

WebKit a réécrit l’ES module loader de Safari pour la conformité aux standards, corrigeant plusieurs bugs de conformité liés à top-level await. L’implémentation précédente était fondée sur une proposition WHATWG Loader abandonnée de 2016 qui précédait top-level await, et pouvait laisser des imports accéder à des exports avant qu’ils ne soient pleinement initialisés.¹

appearance: base est-il livré ?

appearance: base-select est livré dans Safari 27 pour l’élément <select>, effaçant le style natif afin que vous puissiez appliquer votre propre CSS tout en conservant la sémantique du contrôle.¹ Étendre appearance: base à tous les contrôles de formulaire est une orientation annoncée mais une spécification non figée, et le panel du labo a ouvertement exprimé son désaccord sur ce à quoi le rendu par défaut non stylé devrait ressembler.²

Apple a-t-il vraiment ajouté des extensions Safari générées par IA ?

Oui. Apple a annoncé « Describe an Extension » lors du keynote de la WWDC 2026 : il utilise Apple Intelligence pour générer et installer une extension Safari sur mesure à partir d’une description en langage naturel, sans Xcode ni l’App Store.⁹ C’est une fonctionnalité grand public, pas une API de développeur.

Les articles sur les fonctionnalités de Safari couvrent le quoi : styler le vrai <select>, CSS Grid Lanes pour le masonry natif et l’élément HTML <model>. Celui-ci couvre le pourquoi derrière le rythme. Le hub complet de la série est la Série Écosystème Apple.

Références