Chrome Dev Insider: édition CSS et UI

Bienvenue dans la deuxième édition de Chrome Dev Insider, dans laquelle nous partageons des informations sur les nouveautés et les nouveautés intéressantes dans la communauté et ici chez Chrome. Il s'agit d'un nouvel épisode de témoignages d'initiés sur la façon dont nous abordons notre travail, ainsi que d'un bref aperçu de certaines des nouveautés les plus importantes auxquelles vous devez prêter attention.

Je m'appelle Rachel Andrew, je suis responsable de contenu pour web.dev et developer.chrome.com, et je fais partie de l'équipe Chrome chargée des relations avec les développeurs. Je travaille sur le Web depuis plus de vingt ans, en me concentrant sur les normes du Web ouvert et les CSS, et je suis membre du groupe de travail CSS.

Il y a deux mois, à la fin de la conférence Google I/O, nous avons annoncé certaines des informations les plus importantes sur la façon dont nous aidons les développeurs à rendre le Web plus rapide et plus puissant, tout en assurant la sécurité et la confidentialité des informations utilisateur.

L'un des points forts du site (et nous sommes ravis que la communauté a pris en compte le problème) est le travail considérable qu'effectue l'équipe pour prendre en charge davantage de fonctionnalités CSS et UI sur le Web. Dans cette édition de Chrome Dev Insider, nous vous présenterons qui se cache derrière ce travail, comment nous aidons les développeurs CSS et UI, et ce qui vous attend. C'est pourquoi je suis ravi d'animer cette édition de The Insider.

Actualités

Dans le premier article Chrome Dev Insider, nous avons présenté des informations sur les initiatives de Compat 2021 et d'Interop 2022 dans lesquelles les fournisseurs de navigateurs et les acteurs de l'écosystème se sont associés afin d'ajouter sur le Web davantage de fonctionnalités compatibles avec tous les navigateurs. Cette initiative est axée sur les CSS, car l'incompatibilité des navigateurs est l'un des principaux défis pour les développeurs CSS.

Ce n'est peut-être pas une nouveauté pour la plupart des gens, mais nous sommes ravis de constater les progrès que nous avons déjà réalisés avec les différents navigateurs.

Chrome pour les développeurs à 71, Firefox Nightly à 74, Safari TP à 73.
Scores pour les navigateurs expérimentaux en mars 2022
Chrome pour les développeurs à 77, Firefox Nightly à 80, Safari TP à 80.
Scores issus des navigateurs expérimentaux en juillet 2022. Voir les derniers scores

Au début du mois dernier, Safari a annoncé une version de bumper avec Safari 16.0 bêta qui inclut des fonctionnalités intéressantes telles que les requêtes de conteneur, la sous-grille subgrid et un outil d'inspection Flexbox. Les dernières versions de Firefox et de Chrome ont inclus un certain nombre de fonctionnalités et de correctifs intéressants. Chaque mois, j'aborde les principaux points des navigateurs stables et bêta dans ma série d'articles intitulée Nouveautés de la plate-forme Web.

Point pour les initiés: aider les développeurs de CSS et d'UI

L'année 2022 s'annonce passionnante pour les fonctionnalités CSS, nous avons pensé que le moment était idéal pour vous faire découvrir les coulisses. J'ai rencontré Una Kravets, DevRel Lead pour l'UI Web et les outils de développement, et Nicole Sullivan, notre responsable produit pour l'UI Web, spécialiste des API CSS et HTML, pour nous expliquer comment Chrome accompagne les développeurs d'interfaces utilisateur.

Commençons par vous deux. Pouvez-vous nous en dire un peu plus vous concernant ?

Nicole:Je suis responsable produit pour l'interface utilisateur Web sur Chrome. Je me concentre spécifiquement sur les nouvelles API CSS et HTML, ainsi que sur les développeurs et les concepteurs qui créent des interfaces utilisateur. C'est un espace passionnant, avec la sortie de quelques API très importantes, telles que les requêtes de conteneurs, le champ d'application et, si possible, le rythme vertical.

Una:je dirige les équipes DevRel liées à l'interface utilisateur Web et aux outils de développement. Nous nous efforçons d'aider les ingénieurs en interface utilisateur sur la plate-forme Web et nous nous assurons qu'ils disposent des outils dont ils ont besoin pour réussir. Cela inclut les API CSS, les composants HTML et les fonctionnalités des outils de développement pour afficher les modifications actives et les commentaires.

Ces dernières années, l'assistance proposée par Chrome aux développeurs d'interface utilisateur n'a cessé d'augmenter. Pourquoi pensez-vous qu'il a fallu autant de temps pour en arriver là ? Quels ont été les plus grands défis ?

Una:nous devions nous efforcer de démontrer l'importance de ce travail et pourquoi il devrait être une priorité. Nous avons commencé par l'enquête sur l'ADN du Réseau de Recherche (MDN) en 2019, dans laquelle l'interface utilisateur constituait l'une des principales difficultés de la plate-forme. Depuis, nous continuons d'utiliser les données comme guide par le biais du MDN et de nos propres enquêtes de satisfaction internes auprès des développeurs. Résultat : nous avons réussi à obtenir davantage d'adhésion de la direction et à prioriser les tâches d'ingénierie autour de certaines des fonctionnalités les plus demandées par les développeurs dans l'espace de l'interface utilisateur. C'est également le point central d'initiatives telles que Compat 2021 et Interop 2022.

Nicole:En plus d'obtenir l'adhésion des responsables, nous avons dû trouver le bon moyen de proposer ces API aux développeurs. Lorsque j'ai rejoint Chrome, j'ai commis une erreur dans un projet appelé Layered APIs (API en couches). Les LAPI visent à offrir aux développeurs une expérience de composants prête à l'emploi. Je pense toujours que c'était un bon résultat, mais nous avons fait beaucoup d'erreurs ! Nous nous sommes d'abord concentrés sur les notifications de toast et la liste virtuelle. Les toasts sont presque impossibles à rendre accessibles et une liste virtuelle est l'un des composants les plus difficiles à obtenir. Nos intentions étaient bonnes, mais notre projet n'aidait pas les développeurs. Nous avons donc arrêté ce projet. Il est difficile d'apprendre à la base, mais chaque erreur est à l'origine de la renaissance des langages CSS et HTML en ce moment.

Parlons un peu plus des LAPI. Pourquoi ?

Nicole:Pour les LAPI, nous savions que le Web avait besoin d'une expérience de développement de composants prête à l'emploi, plus proche de la création d'une UI native. Et il était clair que réinventer la roue freinait les développeurs. Je n'arrive pas à compter le nombre d'onglets que j'ai construits dans ma carrière ! Ceci étant dit, nous avons essayé d'envoyer JavaScript avec le navigateur, ce qui était très difficile. Personne n'avait envoyé JavaScript dans ce navigateur auparavant, et la manière dont il devait interagir avec le code C++ sur lequel repose le moteur de rendu du navigateur n'était pas claire. Nous avons pris en compte d'autres fournisseurs de navigateurs (merci, Mozilla !) et avons abandonné cette approche, ce qui nous a permis de trouver une solution bien meilleure avec Open UI. En adoptant les langages HTML et CSS, nous obtenons des solutions déclaratives et flexibles. Comme il s'agit d'un processus déclaratif, nous pouvons intégrer l'accessibilité d'une manière qui n'aurait pas été aussi facile à faire avec JavaScript. J'ai vraiment hâte de savoir où ça va aller. Nous travaillons sur la prise en charge de selectmenu, pop-up, info-bulle, nav, accordéon, onglets, carrousel et bouton d'activation, qui sont des modèles de conception d'interface utilisateur essentiels.

Nous avons donc beaucoup appris. Je sais que d'autres initiatives ont été lancées dans ce domaine, comme le CSS Houdini. De quoi parle-t-on ?

Una:Oui, le CSS Houdini a également tiré des enseignements de la communauté. Il existe de nombreuses fonctionnalités d'Houdini utiles, mais beaucoup étaient trop de bas niveau pour être adoptées et adoptées par un plus grand nombre. Nous avons réalisé que l'implémentation d'API de bas niveau ne générait pas nécessairement des problèmes de friction pour les développeurs. En se concentrant sur les solutions et les besoins de plus haut niveau, nous avons pu obtenir une prise en charge multi-navigateurs et obtenir les pages de destination nécessaires pour faire évoluer l'écosystème. Nous suivons l'avancée des opérations à l'adresse https://ishoudinireadyyet.com/.

En ce qui concerne la compatibilité multinavigateur, des initiatives comme Interop 2022 et Open UI semblent générer d'importants résultats positifs pour la communauté. Que pensez-vous des développeurs ?

Una:l'une des principales difficultés rencontrées par les développeurs est de "faire en sorte que la conception fonctionne de la même manière sur tous les navigateurs". Nous avons résolu ce problème en collaborant avec d'autres fournisseurs de navigateurs afin de hiérarchiser certaines des fonctionnalités les plus demandées par les développeurs et de les intégrer en priorité. Les commentaires de la communauté ont été extrêmement positifs. De plus, grâce à un gros effort de refonte de l'architecture, appelé RenderingNG, il est devenu possible d'intégrer certaines de ces fonctionnalités de manière beaucoup plus efficace. Les développeurs se réjouissent de voir que ces fonctionnalités tant attendues depuis des années sont en train d'être développées et disponibles sur plusieurs navigateurs.

Nicole:L'enthousiasme dans la communauté est palpable. Vous pouvez le vérifier sur Twitter. :)

Le tweet mentionné au paragraphe précédent.

Notre collaboration avec l'écosystème s'est avérée essentielle pour nous aider à faciliter la vie des développeurs. Je sais que votre équipe y a beaucoup travaillé. Pourriez-vous nous en dire plus ?

Nicole:Tout d'abord, je suis constamment impressionné par les projets que les développeurs créent sur le Web. Qu'il s'agisse de la bibliothèque la plus infime ou des frameworks complets, les développeurs peuvent créer des applications incroyables. C'est une communauté fantastique de créateurs. Chrome met tout en œuvre pour faciliter la connexion à ces projets.

Par exemple, il y a quelques années, nous avons commencé à travailler avec des frameworks JavaScript tels que React et Angular. et les métaframeworks tels que Next, Nuxt et Gatsby. L'année dernière, nous avons commencé à faire de même avec des outils et des frameworks d'UI tels que Sass, Bootstrap et Material. J'espère que cette année à venir, nous pourrons collaborer avec GreenSock et d'autres outils qui faciliteront la vie des développeurs. Je viens de voir Cassie Evans de GreenSock parler à la Smashing Conference et cela m'a vraiment enthousiaste à l'idée de travailler avec une équipe dans le domaine de l'animation.

Quelles sont les principales opportunités pour l'écosystème des UI Web ?

Una:En ce qui concerne les opportunités importantes, je pense que nous ne faisons qu'effleurer la surface des expériences Web personnalisables. De nouvelles API, telles que les requêtes de conteneur et les fonctionnalités multimédias de préférences utilisateur CSS, redéfinissent l'approche du responsive design pour les développeurs. Je suis également enthousiasmé par les expériences de conception collaborative qui permettent aux développeurs et aux concepteurs de travailler à l'unisson avec les utilisateurs qui visitent leurs sites Web.

Nicole, quel est le prochain projet de votre équipe ?

Nicole:Toutes les explorations ne donnent pas lieu à une expédition, mais il y a de nombreux aspects qui m'intéressent vraiment:

Sans parler du premier point, nous favorisons une conception réactive et basée sur des composants. Elle comprend des outils de conception de systèmes de couleurs afin que les concepteurs puissent répondre aux préférences des utilisateurs comme le mode sombre. Par exemple, l'espace colorimétrique OKLCH assure la cohérence de la luminosité entre les teintes. Les concepteurs peuvent passer du choix des couleurs à la conception de relations entre les couleurs, sans se retrouver avec des palettes boueuses !

Nous travaillons également sur certaines des API les plus demandées, comme les requêtes de conteneur, les couches de cascade, le sélecteur parent (:has), les styles de champ d'application et l'imbrication. Les développeurs en ont besoin pour pouvoir créer des systèmes de conception flexibles remplis de composants réutilisables.

Les animations liées au défilement sont une autre zone amusante. J'aime beaucoup la démonstration de Steve Gardner. Il propose un défilement fluide et des animations d'avions sympas déclenchées par le défilement. Bien qu'ils soient amusants, il peut être difficile de bien les comprendre, surtout en ce qui concerne l'accessibilité. Nous testons donc l'accessibilité de la fonctionnalité auprès des utilisateurs.

Ce qui me passionne le plus, ce sont les commandes intégrées de l'interface utilisateur Web. Les développeurs ne cessent de créer le même jeu d'onglets. Je pense que le navigateur peut être utile. Dans Open UI (Ouvrir l'interface utilisateur), nous travaillons sur des composants tels que selectmenu, pop-up, info-bulle, onglets, navigation, accordéon et bouton d'activation. Nous envisageons d'intégrer l'accessibilité dans ces primitives de navigateur afin que le Web puisse, au fil du temps, devenir accessible par défaut. Les développeurs peuvent ensuite se concentrer sur les problèmes les plus complexes et les plus nuancés, tandis que le navigateur prend en charge les notions de base, comme l'onglet "Comment faire les onglets". Il a probablement besoin de son propre post, donc je vais en rester là pour le moment !

Enfin, nous poursuivrons nos efforts pour améliorer l'interopérabilité entre les navigateurs. Nous avons beaucoup travaillé avec les membres de WebKit et Gecko pour harmoniser l'expérience des développeurs. Les développeurs nous ont indiqué clairement qu'ils en voulaient.

Si vous ne l'avez pas encore fait, l'API Shared Element Transitions (API Shared Element Transitions) va changer la façon dont les utilisateurs conçoivent pour le Web. Toutes ces petites transitions subtiles qui permettent aux concepteurs d’orienter leurs conceptions dans l’espace physique seront non seulement possibles, mais faciles. Jake Archibald propose une excellente démo.

Si les standards sont populaires, nous pourrions même considérer le rythme vertical cette année ! Nous pouvons nous appuyer sur LayoutNG, qui débloque de nombreuses fonctionnalités.

Merci à tous les deux. Je suis sûr que toute la communauté, comme nous, est enthousiaste à l'idée de voir le rythme des améliorations et des fonctionnalités arriver dans l'interface utilisateur Web. Il y a encore beaucoup à faire. Par où commencer ?

Una:notre session What's new for the web platform de Google I/O aborde les points forts de nombreuses fonctionnalités que nous allons lancer cette année. Adam Argyle a également rédigé un article intéressant sur toutes les nouvelles et prochaines sorties CSS. De manière continue, je me concentrerais sur les versions stables pour le moment et je serais informée des autres tâches à venir. Nous vous invitons à suivre pour cela votre série de messages intitulée New to the web platform (Nouveaux utilisateurs de la plate-forme Web). Si vous vous abonnez à la newsletter web.dev, ce contenu sera également envoyé dans la boîte de réception des développeurs. Et pour les développeurs qui souhaitent s'impliquer et aider sur tous ces points, rejoindre Open UI est l'un des meilleurs moyens de faciliter leur travail.

Principales nouveautés à venir

Dans cette optique, nous souhaitons vous informer d'un changement à venir que vous devez garder à l'esprit lorsque vous développez des expériences Web.

Limiter l'âge maximal pour les cookies à 400 jours

  • Mise à jour:lorsque les cookies sont définis avec un attribut Expires/Max-Age explicite, leur valeur est désormais limitée à un maximum de 400 jours à l'avenir. Auparavant, il n'y avait pas de limite et les cookies pouvaient expirer plusieurs millénaires à l'avenir. Cette limite vise à trouver l'équilibre entre les schémas d'utilisation courants et le respect de la confidentialité des utilisateurs. Les sites consultés plus de 400 jours peuvent actualiser les cookies pour assurer la continuité du service. De plus, les utilisateurs sont assurés que les cookies ne resteront pas dans leur navigateur pendant des millénaires sans les utiliser.
  • Délai estimé:expédition dans Chrome 104 (stable à compter du 2 août 2022).
  • Incitation à l'action du développeur:les développeurs devront peut-être actualiser les cookies plus souvent de manière proactive que par le passé lorsque les utilisateurs consultent leurs sites Web. Sinon, les utilisateurs risquent d'être déconnectés 400 jours après la définition initiale du cookie.

J'espère que vous avez apprécié cette édition de Chrome Dev Insider. Si vous l'avez manqué, voici la première. Nous sommes impatients de vous en faire profiter au cours du prochain trimestre.

En attendant, donnez-nous votre avis sur cette édition de Chrome Dev Insider et sur ce que nous pouvons faire pour l'améliorer.

Qu'avez-vous pensé de cette édition de The Chrome Dev Insider ? Donnez-nous votre avis.