Disponible sur les principaux systèmes, Chrome 142 beta introduit une série d’évolutions qui touchent aussi bien le CSS, l’UX des composants natifs, les Web APIs que l’architecture de sécurité. Pour les équipes produit, design et ingénierie, ce millésime marque une consolidation de chantiers entamés ces derniers mois : transitions de vues plus maîtrisées, requêtes de style plus expressives, parité de rendu mobile/desktop, capacités WebGPU étendues et durcissement des règles d’isolement par origine. Tour d’horizon des changements à connaître avant vos prochains sprints.
Deux nouvelles pseudo-classes, :target-before et :target-after, permettent de cibler les marqueurs de défilement situés respectivement avant et après le marqueur actif (défini via :target-current) au sein d’un même groupe. En pratique, cela facilite la mise en scène d’indicateurs de progression sur des timelines, carrousels ou sommaires collants, en distinguant visuellement ce qui précède et ce qui suit l’état courant, selon l’ordre du flat tree.
Le pseudo-élément racine des transitions de vue adopte désormais position : absolute (au lieu de fixed). Le bloc de conteneur des instantanés reste identique, si bien que l’impact visuel est nul dans la majorité des cas. Le principal changement se perçoit via getComputedStyle, ce qui peut intéresser les outils de diagnostic et les bibliothèques qui inspectent dynamiquement les styles.
L’API View Transitions gagne en ergonomie : plus besoin de conserver l’objet retourné lors d’un startViewTransition() dans vos états applicatifs. Une propriété document.activeViewTransition expose l’objet de transition en cours (ou null si aucune n’est active). Ce comportement vaut également pour les transitions de type MPA ; pendant la durée de la transition, l’objet devient accessible, notamment entre les événements de pageswap et de pagereveal.
Les style queries et la fonction if() acceptent des comparateurs de valeur (par exemple supérieur/inférieur) pour confronter propriétés personnalisées, valeurs littérales et substitutions issues de fonctions comme attr() ou env(). Cette comparaison est valable si les deux côtés se résolvent au même type de données, limité aux familles numériques usuelles : longueurs, nombres, pourcentages, angles, durées, fréquences et résolutions. Concrètement, vous pouvez conditionner un style si une variable CSS dépasse un seuil, ou comparer deux constantes, et propager cette logique dans if() pour adapter vos composants sans JavaScript additionnel.
Un nouvel attribut, interestfor, est disponible sur les éléments <button> et <a>. Il confère des comportements d’« intérêt » capables de déclencher des actions sur une cible (comme l’affichage d’un popover) lorsque l’utilisateur manifeste une intention claire : survol prolongé, combinaison de touches dédiée, appui long sur écran tactile. Un InterestEvent est émis à l’apparition comme à la perte d’intérêt, avec des actions par défaut adaptées aux popovers (afficher/masquer), ce qui simplifie l’implémentation de micro-interactions fiables.
Chrome adopte la propriété CSS font-language-override, qui permet de piloter directement dans la feuille de style le tag linguistique OpenType utilisé pour les substitutions de glyphes. Idéal pour des interfaces multilingues ou des polices dotées de variantes spécifiques, ce levier donne un contrôle fin sans devoir recourir à des contournements côté police ou JavaScript.
L’attribut download est désormais pris en charge sur les liens SVG, avec un comportement calqué sur les liens HTML. Au clic, au lieu de naviguer, le navigateur télécharge la ressource ciblée. À la clé : interopérabilité accrue entre HTML et SVG, et attentes utilisateur plus prévisibles dans les interfaces vectorielles interactives.
Le contrôle <select> harmonise ses modes de rendu entre mobile et desktop, en tenant compte des attributs size et multiple. L’objectif : garantir qu’un même balisage produise un comportement cohérent, quel que soit l’appareil.
Cette parité facilite la conception d’UI accessibles et prévisibles, en évitant les divergences de patterns selon le device.
La « sticky user activation » est conservée lorsque l’application navigue vers une page de même origine, ce qui débloque des scénarios comme l’affichage automatique d’un clavier virtuel sur autofocus juste après une transition. Sont exclus les cas initiés par le navigateur (rechargement, navigation d’historique, saisie d’URL…).
WebGPU expose un nouvel identifiant de primitive au niveau des fragment shaders, sur matériel compatible. Comparable aux builtins existants pour les sommets et les instances, cet index par primitive ouvre la voie à des techniques avancées (par exemple géométrie virtualisée), avec un adressage plus riche au moment du shading.
Les formats de textures progressent vers des capacités de « tier 1 » et « tier 2 », incluant attachements de rendu, blending, multisampling, opérations de resolve et storage binding. Cela élargit le périmètre des pipelines graphiques réalisables directement dans le navigateur.
Les événements d’édition avec les types insertFromPaste, insertFromDrop et insertReplacementText exposent désormais la propriété dataTransfer pendant l’édition dans les zones contenteditable. Son contenu reflète ce qui était disponible durant beforeinput, ce qui simplifie les éditeurs WYSIWYG et l’inspection des données du presse-papiers ou du drag-and-drop. À noter : cela ne s’applique pas aux champs de formulaire standards (textarea, input).
Les détails d’actions de la Media Session API incluent enterPictureInPictureReason pour distinguer une entrée au PiP déclenchée par l’utilisateur (via une commande explicite) d’une entrée automatique due à l’occlusion du contenu par le navigateur. De quoi adapter votre UI et vos analytics selon l’intention réelle.
Les sites peuvent fournir et mettre à jour une liste de phrases afin de biaiser le modèle de reconnaissance vocale en faveur de termes attendus. Cette approche améliore la précision dans des contextes métier ou personnalisés, sans sacrifier la flexibilité du moteur.
Les réponses de modules JSON sont rejetées si le type ou le sous-type MIME associé au motif *+json contient des caractères non autorisés (par exemple des espaces). Cette mise en conformité avec la spécification de détection MIME, déjà suivie par d’autres moteurs, fait partie des efforts Interop2025 autour des modules.
Lorsque l’iframe n’est pas conceptuellement premier niveau, l’interface de FedCM peut désormais présenter l’origine de cet iframe plutôt que celle du site parent. Les utilisateurs comprennent ainsi plus clairement à qui ils confient leurs identifiants. Exemple typique : un éditeur photo embarqué dans une application d’édition de livres qui demande l’accès à des fichiers précédemment stockés.
Chrome affine son modèle d’isolation en passant d’un verrouillage par site (exemple.com) à un verrouillage par origine (foo.example.com). Chaque origine obtient son propre process de rendu, en adéquation avec le modèle de sécurité du Web. Résultat : des frontières plus nettes et une réduction de la surface d’attaque intra‑site.
Conformément à la spécification Pointer Events, l’événement pointerrawupdate n’est exposé que dans des contextes sécurisés. Chrome aligne ainsi son comportement sur les autres navigateurs et renforce l’Interop tout en protégeant des usages sensibles hors HTTPS.
Un mécanisme permettant d’associer de manière sûre une session à un seul appareil. Le navigateur peut renouveler la session à la demande du serveur en prouvant la possession d’une clé privée, ce qui renforce la résistance aux détournements de session.
Expérimentation d’un double changement : élargir la taille du pool TCP par profil tout en ajoutant un plafond par site de premier niveau afin d’éviter qu’un petit nombre d’onglets n’épuise toutes les connexions disponibles. Les limites sont appliquées indépendamment aux pools WebSocket et HTTP. Si aucun effet négatif n’est observé, l’intention est d’aller vers un déploiement.
Chrome 142 beta instaure des fondations plus robustes pour les expériences riches. Voici quelques pistes d’action concrètes pour capitaliser rapidement sur ces nouveautés :
En synthèse, Chrome 142 beta peaufine les détails qui comptent au quotidien pour les designers et développeurs : moins de disparités entre plateformes, davantage de contrôle sémantique en CSS, des API mieux intégrées à l’UX et une sécurité renforcée au niveau du processus. Intégrez ces évolutions à vos cycles de QA, activez les origin trials pertinents pour votre produit et préparez vos bibliothèques internes à cette nouvelle étape.
ChatGPT accueille des applications : un nouveau terrain de jeu pour l’idéation et la productivité…
Une nouvelle ère de recherche pour l’Europe Google ouvre un nouveau chapitre de la recherche…
Perplexity franchit une nouvelle étape stratégique avec l’acquisition de l’équipe derrière Visual Electric, une jeune…
Du gadget au véritable canal de venteLongtemps perçus comme un mélange de curiosité technologique et…
Une Nouvelle Révolution dans la Création de Contenu : Présentation du Sora 2 et Sa…
La toute dernière version de Nuxt UI, la v4, marque un tournant décisif pour les…