Chrome 110 bêta

Lettres initiales CSS, gestionnaire de lancement d'application Web, compatibilité des iFrame multi-origines avec l'API FedCM, et plus encore.

Sauf indication contraire, les modifications décrites ci-dessous s'appliquent à la dernière version bêta de Chrome pour Android, ChromeOS, Linux, macOS et Windows. Pour en savoir plus sur les fonctionnalités listées ici, cliquez sur les liens fournis ou consultez la liste sur ChromeStatus.com. Chrome 110 est en version bêta depuis le 12 janvier 2023. Vous pouvez télécharger les dernières versions sur Google.com pour ordinateur ou sur le Google Play Store sur Android.

CSS

Cette version inclut deux nouvelles fonctionnalités CSS.

Lettres initiales du CSS

Les lettres initiales sont de grandes lettres décoratives qui sont utilisées pour créer des sections de texte depuis avant l'invention de l'imprimerie. La propriété CSS initial-letter permet de définir le nombre de lignes qu'une lettre initiale doit caler dans les lignes de texte suivantes. Dans l'exemple suivant, la première lettre s'affiche sur trois lignes de texte.

.content::first-letter {
  initial-letter: 3;
}

Paragraphe de texte contenant une lettre initiale en trois lignes du paragraphe.

Pseudo-classe CSS :picture-in-picture

La pseudo-classe :picture-in-picture aide les développeurs Web à personnaliser le lecteur multimédia lorsque des vidéos entrent ou sortent du mode Picture-in-picture.

Essayez une démo de la pseudo-classe :picture-in-picture.

API Web

AudioContext.setSinkId()

AudioContext.setSinkId définit l'ID de l'appareil audio à utiliser pour la sortie. Cela permet à AudioContext d'acheminer le contenu audio vers un périphérique de sortie connecté choisi par l'utilisateur.

Pour en savoir plus sur cette fonctionnalité, consultez l'article Modifier le périphérique de sortie de destination pour les annonces audio sur le Web.

FedCM dans un iFrame multi-origine

Ajout de la prise en charge des iFrame multi-origines pour l'API FedCM via une règle d'autorisation. Il permet aux sites Web de stocker dans un bac à sable les scripts des fournisseurs d'identité qui déclenchent l'API FedCM dans un iFrame multi-origine, afin qu'ils n'aient pas un contrôle total sur l'ensemble de la page. Cela permet également les cas d'utilisation où l'iFrame lui-même nécessite une connexion de la part de l'utilisateur. Dans les deux cas, le frame parent doit fournir l'iFrame multi-origine avec la règle d'autorisation identity-credentials-get.

Sans identifiant iFrame

Le modèle sans identifiant iFrame permet aux développeurs de charger des documents dans des cadres iFrame tiers à l'aide de contextes nouveaux et éphémères. Il s'agit d'une généralisation du protocole COEP sans identifiant pour prendre en charge les iFrames tiers susceptibles de ne pas déployer COEP. Cela supprime la contrainte selon laquelle les iFrame tiers doivent prendre en charge le COEP pour être intégrés dans une page COEP et débloquera les développeurs qui souhaitent adopter l'isolation multi-origine.

En savoir plus sur l'utilisation sans identifiant d'iFrame

Méthode FileSystemHandle::remove()

La méthode remove() de FileSystemHandle permet le cas d'utilisation courant où vous obtenez un handle de fichier auprès de showSaveFilePicker(), puis décidez de ne pas enregistrer le fichier et de le supprimer. Avant l'ajout de cette méthode, il était impossible de supprimer un fichier ou un répertoire en raison de son identifiant. Vous avez dû obtenir le handle du répertoire parent et appeler FileSystemDirectoryHandle::removeEntry().

Préchargement déclenché par l'API des règles de spéculation

Le préchargement récupère la ressource principale pour une navigation future et la conserve en mémoire afin qu'elle puisse être utilisée pour accélérer la navigation suivante. Cette nouveauté inclut à la fois le préchargement sur le même site et le préchargement intersite dans le cas où aucun identifiant n'est présent pour le site de destination.

Utiliser le traitement IDNA non transitionnel dans les URL

Activer IDNA 2008 en mode non transitionnel pour le traitement des URL, en alignant le comportement de Chrome avec celui de Firefox et Safari Chrome utilise actuellement IDNA 2008 en mode transitionnel pour le traitement des URL. La principale différence entre le mode de transition et le mode non transitionnel réside dans le traitement de quatre caractères appelés caractères de déviation: ß (LATIN Small LETTER SHARP S), shape (GREEK small LETTER FINAL SIGMA), ZWJ (Zero width joiner) et ZWNJ (Non-jointure à largeur zéro). En mode Transitional, les caractères de déviation sont traités de la même manière que IDNA2003: ß est mappé à ss, Quelle est mappée à resolve, et ZWJ et ZWNJ sont supprimés. En mode non transitionnel, les domaines contenant ces caractères sont autorisés dans les noms de domaine sans mappage. Ils peuvent donc être associés à des adresses IP différentes. Par exemple, si vous saisissez faß.de dans Chrome, Firefox ouvre différents sites aujourd'hui. L'activation de l'IDNA non transitoire dans Chrome autorisera les caractères d'écart dans les noms de domaine. Firefox et Safari ont déjà effectué ce changement en 2016 et continuent d'utiliser le traitement non transitionnel des URL.

Gestionnaire de lancement d'applications Web

Ajoutez un membre du fichier manifeste d'application Web launch_handler qui permet aux applications Web de personnaliser leur comportement de lancement pour tous les types de déclencheurs. Par exemple, avec le code suivant, tous les lancements de l'application XXX placeront une fenêtre d'application existante et la parcouriront (le cas échéant), au lieu de lancer systématiquement une nouvelle fenêtre d'application.

{
    "name": "Example app",
    "start_url": "/index.html",
    "launch_handler": {
        "client_mode": "navigate-existing"
    }
}

règles d'autorisation de partage Web

Contrôle l'accès à navigator.share(). Par défaut, les iFrames tiers ne sont pas autorisés à utiliser l'API Web Share.

Essais d'origine en cours

Dans Chrome 110, vous pouvez activer les nouvelles phases d'évaluation suivantes.

Prise en charge de No-Vary-Search dans le cache de préchargement de la navigation

Active la mise en correspondance du préchargement même si les paramètres de requête d'URL sont modifiés. L'en-tête de réponse HTTP No-Vary-Search déclare qu'une partie ou la totalité d'une requête d'URL peut être ignorée à des fins de mise en correspondance du cache. Il peut déclarer que l'ordre des clés de paramètre de requête ne doit pas provoquer de défauts de cache, que des paramètres de requête spécifiques ne doivent pas entraîner de défauts de cache ou que seuls certains paramètres de requête connus doivent être à l'origine de défauts de cache. Elle peut s'appliquer à plusieurs caches, mais cette entrée fait référence à la prise en charge du cache de préchargement.

Inscrivez-vous pour bénéficier de l'assistance No-Vary-Search dans le cadre d'un essai de préchargement du cache Navigation.

PerformanceResourceTiming.deliveryType

Exposer des informations sur la façon dont une ressource a été livrée. Par exemple, il est utile d'identifier les ressources fournies à partir du cache (actuellement exposées via transferSize) et les navigations qui ont été préchargées par la page précédente.

Entrée des performances de SoftNavigation

Exposition des heuristiques de navigation douce (expérimentales) aux développeurs Web à l'aide de PerformanceObserver et de la chronologie des performances.

Inscrivez-vous à l'essai heuristique de navigation douce.

Règles de spéculation: diffusion via l'en-tête Speculation-Rules

Actuellement, les développeurs ne peuvent spécifier des règles de spéculation qu'à l'aide de tags de script intégrés. La fonctionnalité proposée fournit une alternative via l'en-tête "Speculation-Rules". Sa valeur doit correspondre à l'URL d'une ressource textuelle avec le type MIME application/speculationrules+json. Les règles de la ressource seront ajoutées au jeu de règles du document.

Règles de spéculation: règles basées sur des documents

Extension de la syntaxe des règles de spéculation qui permet au navigateur d'obtenir des URL à spéculer à partir des liens d'une page. Ils peuvent inclure des critères limitant leur utilisation.

X-Requested-With dans WebView

Essai d'abandon pour conserver l'ancien comportement de X-Requested-Header sur Android WebView. Cet en-tête est actuellement défini avec le nom de package de l'application d'intégration en tant que valeur, mais ce comportement sera supprimé lors d'un déploiement lent. Pendant la période d'abandon, cet essai permettra aux propriétaires de sites de continuer à recevoir l'en-tête pendant la migration.

Vous trouverez plus d'informations sur cet abandon dans un autre article de blog. Inscrivez-vous ici à l'essai d'abandon de X-Requested-With.

Abandons et suppressions

Cette version de Chrome présente les abandons et suppressions listés ci-dessous. Consultez la page ChromeStatus.com pour consulter la liste des abandons planifiés, des abandons actuels et des suppressions précédentes.

Cette version de Chrome supprime deux fonctionnalités.

Supprimer Web SQL dans les contextes non sécurisés

Web SQL est désormais supprimé dans les contextes non sécurisés. Nous vous recommandons de passer à SQLite Wasm dans le navigateur reposant sur le système de fichiers d'origine privé.

Suppression de window.webkitStorageInfo

Suppression de la prise en charge de l'ancienne API de quota de stockage, window.webkitStorageInfo. Lancée à l'origine en 2011, Chrome a implémenté l'API de quota préfixée, qui a été immédiatement remplacée par l'API Quota, qui est également obsolète depuis. L'ancienne API de quota de stockage n'a jamais été mise en œuvre par un autre navigateur et est marquée comme obsolète depuis 2013.