Chrome 94 est disponible et s'accompagne de l'API Idle Detection pour détecter l'inactivité des utilisateurs

Malgré les problèmes de confidentialité exprimés par Mozilla et Apple

Google publie la version bêta de Chrome 94 avec la promotion de l'API WebCodecs, l'essai de WebGPU Origin
et l'API VirtualKeyboard

Google a annoncé la disponibilité de la version bêta de Chrome 94 jeudi. Cette nouvelle version ajoute de nouvelles fonctionnalités au navigateur et apporte également quelques améliorations. Dans un billet de blogue, Google a déclaré que Chrome 94 Beta marque l'achèvement de l'API WebCodecs dans le cadre de son essai d'origine et donc maintenant officiellement disponible. WebGPU fait son entrée dans la phase d'essai initiale de Chrome 94. WebGPU fait partie de la version bêta de Chrome 94 et a pour objectif d'être promu dans Chrome 99. Sauf indication contraire, les modifications dans Chrome 94 Beta s'appliquent à la dernière version bêta de Chrome pour Android, Chrome OS, Linux, macOS et Windows.

WebCodecs

Les API médias existantes (HTMLMediaElement, Media Source Extensions, WebAudio, MediaRecorder et WebRTC) sont de haut niveau et étroitement ciblées. Une API de codec de bas niveau permettrait de mieux prendre en charge les applications émergentes, telles que la diffusion en continu de jeux sensibles à la latence, les effets ou le transcodage côté client et la prise en charge de conteneurs multimédias polyfillables, sans le coût réseau et CPU accru des implémentations de codecs JavaScript ou WebAssembly. L'API WebCodecs comble ces lacunes en offrant un moyen d'utiliser les composants multimédias déjà présents dans le navigateur. Plus précisément :

• décodeurs vidéo et audio ;
• encodeurs vidéo et audio ;
• images vidéo brutes ;
• décodeurs d'image.

Selon la note de version de Chrome 94 Beta, cette fonctionnalité a également terminé son essai d'origine dans Chrome 93 et est désormais disponible par défaut.

WebGPU

L'API WebGPU est le successeur des API graphiques WebGL et WebGL2 pour le Web. Elle offre des fonctionnalités modernes telles que le "calcul GPU" ainsi qu'un accès moins coûteux au matériel GPU et des performances meilleures et plus prévisibles. Il s'agit d'une amélioration par rapport aux interfaces WebGL existantes, qui ont été conçues pour dessiner des images mais qui ne pouvaient être adaptées à d'autres types de calculs qu'au prix d'un effort considérable. WebGPU expose les capacités graphiques modernes, notamment Direct3D 12, Metal et Vulkan, pour effectuer des opérations de rendu et de calcul sur un GPU.


Cette fonctionnalité fait l'objet d'un test d'origine dans Chrome 94, avec l'espoir d'être livrée dans Chrome 99. Selon Google, les avantages de WebGPU par rapport aux technologies précédentes sont les suivants :

• séparation de la gestion des ressources, de la préparation du travail et de la soumission au GPU ;
• des états de pipeline qui fonctionnent de manière similaire aux API du système d'exploitation ;
• des groupes de liaison qui permettent aux pilotes graphiques d'effectuer les préparations nécessaires avant le rendu ;

Scheduling APIs : Priorité accordée à scheduler.postTask()

Selon Google, il est difficile de créer des applications Web qui répondent aux interactions des utilisateurs et qui restent réactives dans le temps. Les scripts sont l'un des principaux responsables de la perte de réactivité. « Prenons l'exemple d'une fonction de "recherche au fur et à mesure de la saisie" : une application dotée de cette fonction doit suivre la saisie de l'utilisateur tout en récupérant et en affichant les résultats. Cela ne tient pas compte de tout ce qui se passe sur la page, comme les animations, qui doivent être rendues de manière fluide », a déclaré l'entreprise.

« Le problème est généralement abordé en découpant et en programmant le travail du fil principal, c'est-à-dire en exécutant le travail de manière asynchrone aux moments opportuns. Cette approche a ses propres problèmes, notamment le fait que quelle que soit la priorité fixée par le développeur, elle est toujours en concurrence avec le fil d'exécution principal, qui ne reconnaît pas la priorité du développeur et qui est également responsable des tâches du navigateur telles que les opérations fetch() et le ramassage des déchets », a-t-elle expliquée.

Google estime que la méthode scheduler.postTask() résout ces dilemmes de planification en permettant aux développeurs de planifier des tâches (callbacks JavaScript) avec un planificateur de navigateur OS à trois niveaux de priorité : blocage de l'utilisateur, visible par l'utilisateur et arrière-plan (user-blocking, user-visible, et background). Il expose également une interface TaskController, qui peut annuler dynamiquement des tâches et modifier leur priorité. Cette fonctionnalité a terminé son essai initial dans Chrome 93 et est maintenant disponible par défaut dans Chrome.

Nouveaux essais d'origine

En plus des éléments ci-dessus, cette version de Chrome introduit les essais d'origine décrits ci-dessous. Les essais d'origine vous permettent d'essayer de nouvelles fonctionnalités et de faire part de vos commentaires sur la convivialité, la praticité et l'efficacité à la communauté des normes Web. Pour vous inscrire à l'un des essais d'origine actuellement pris en charge par Chrome, y compris ceux décrits ci-dessous, visitez le tableau de bord des essais d'origine de Chrome. Microsoft Edge exécute ses propres essais d'origine séparément de Chrome.

Premiers indices pour la navigation

Chrome teste un nouveau code d'état HTTP : 103 Early Hints pour précharger plus tôt les sous-ressources. Lorsqu'une réponse 103 comprend <link rel=preload> ou d'autres en-têtes de lien, Chromium essaie de précharger (et/ou de se préconnecter, de récupérer à l'avance) les ressources spécifiées avant la réception de la réponse finale. Selon Google, cela donne aux développeurs Web un moyen d'optimiser les applications, les sites et les pages.

Essais d'origine terminés

Les fonctionnalités suivantes, qui faisaient auparavant l'objet d'un essai d'origine dans Chrome, sont désormais activées par défaut.

Gestion des couleurs de Canvas

Cette mise à jour officialise le fait que l'espace couleur par défaut des objets CanvasRenderingContext2D et des objets ImageData est sRGB. Cela clarifie le fait que l'interface CanvasRenderingContext2D est entièrement gérée par les couleurs (que toutes les entrées sont converties dans l'espace couleur du canevas). Il s'agissait auparavant de conventions qui n'étaient pas clairement spécifiées. Cette mise à jour apporte les modifications suivantes :

• ajout de paramètres permettant de spécifier un espace couleur non RVB lors de la création d'un objet CanvasRenderingContext2D ou d'un objet ImageData.
• ajout de la prise en charge de l'espace couleur Display P3 pour ces paramètres.

Le contenu affiché par CanvasRenderingContext2D est actuellement limité à l'espace couleur sRGB, ce qui est inférieur aux capacités des écrans et des caméras modernes. Cette fonctionnalité permet de créer un objet CanvasRenderingContext2D qui est dans l'espace couleur Display P3. Cela permet également de lever plusieurs points d'ambiguïté sur le comportement des couleurs de CanvasRenderingContext2D.

L'API VirtualKeyboard

L'interface VirtualKeyboard possède des méthodes et des propriétés permettant de contrôler l'affichage ou le masquage d'un clavier virtuel. Elle déclenche également des événements avec la taille du clavier virtuel lorsqu'il occulte le contenu de la page. Le clavier virtuel est le clavier à l'écran utilisé pour la saisie dans des scénarios où un clavier matériel peut ne pas être disponible.

Contrairement à un clavier matériel, un clavier virtuel peut adapter sa forme pour l'optimiser en fonction de la saisie attendue. Les développeurs ont le contrôle de la forme affichée du clavier virtuel grâce à l'attribut inputmode, mais ont un contrôle limité sur le moment où le clavier virtuel est affiché ou masqué.

Nouvelles fonctionnalités CSS

Alignement des propriétés transform-style: preserve-3d et perspective avec la spécification

Les propriétés transform-style: preserve-3d et perspective sont désormais alignées sur la spécification. La propriété preserve-3d permet aux éléments enfants de participer à la scène 3D du parent, et la propriété perspective applique une transformation de perspective aux éléments enfants. Avant ce changement, Chromium appliquait ces deux effets en se basant sur la hiérarchie du bloc contenant plutôt que sur l'arborescence du DOM, et leur permettait de s'étendre aux éléments sans propriétés liées à la transformation.

Les mots-clés "content" et "min/max/fit-content"

Chrome prend désormais en charge les mots-clés content, min-content, max-content et fit-content comme valeurs pour la propriété flex-basis et son raccourci flex. Le mot-clé content fait en sorte que la taille de base de flex utilise les règles de dimensionnement par défaut comme si flex-basis et la propriété de taille préférée (largeur ou hauteur) étaient toutes deux auto, en ignorant toute largeur ou hauteur spécifiée dans la dimension de l'axe principal lorsque flex-basis est auto. Les autres mots-clés sont les mêmes que d'habitude et donnent plus d'options pour spécifier la taille de base du flex.

Dans les mises en page réactives, lorsque vous ajoutez ou supprimez display:flex à un conteneur, vous deviez parfois ajouter/supprimer des valeurs pour chaque élément individuel. Le mot-clé content élimine ce besoin dans certaines situations.

scrollbar-gutter

La propriété scrollbar-gutter permet de contrôler la présence de gouttières de barre de défilement (l'espace réservé à l'affichage d'une barre de défilement), ce...