Bienvenue dans la deuxième édition de Chrome Dev Insider, dans laquelle nous vous présentons les dernières nouveautés intéressantes au sein de la communauté et de Chrome. Il s'agit d'un nouvel épisode de témoignages d'initiés sur notre approche de notre travail, ainsi qu'un bref aperçu de certaines des informations les plus importantes auxquelles vous devez prêter attention.
Je suis Rachel Andrew, responsable du contenu pour web.dev et developer.chrome.com, et je fais partie de l'équipe chargée des relations avec les développeurs Chrome. Je travaille sur le Web depuis plus de 20 ans, plus particulièrement sur les normes ouvertes du Web et les CSS, et je suis membre du groupe de travail CSS.
Il y a deux mois, nous avons terminé Google I/O au cours duquel nous avons partagé certaines des informations les plus importantes concernant la manière dont nous aidons les développeurs à rendre le Web plus rapide et plus performant, tout en assurant la sécurité et la confidentialité des informations des utilisateurs.
L'une des choses qui s'est démarquée (et nous sommes heureux que la communauté ait été avertie) est le travail considérable que l'équipe accomplit pour assurer la compatibilité d'un plus grand nombre de fonctionnalités CSS et de l'interface utilisateur sur le Web. Dans cette édition de Chrome Dev Insider, nous vous expliquons qui est à l'origine de ce travail, comment nous aidons les développeurs CSS et UI, et ce qui les attend. Je suis donc ravi d'organiser cette édition d'The Insider.
Lieu à la une
Dans le premier document Chrome Dev Insider, nous avons partagé des informations sur les initiatives Compat 2021 et Interop 2022, dans lesquelles les fournisseurs de navigateurs et les acteurs de l'écosystème se sont associés pour proposer davantage de fonctionnalités sur le Web, compatibles avec tous les navigateurs. Cette initiative met particulièrement l'accent sur les CSS, car l'incompatibilité avec les navigateurs constitue l'un des principaux défis pour les développeurs CSS.
Même si ce n'est peut-être pas une nouveauté pour la plupart des utilisateurs, nous sommes ravis de constater les progrès que nous avons déjà réalisés dans les différents navigateurs.
Le mois dernier, nous avons vu l'annonce d'une version de bumper dans Safari 16.0 bêta incluant des fonctionnalités intéressantes telles que les requêtes de conteneurs, la sous-grille et un outil d'inspection flexible. Les dernières versions de Firefox et de Chrome incluent un certain nombre de fonctionnalités et de correctifs intéressants. Chaque mois, j'aborde les points essentiels des navigateurs stables et bêta dans ma série de posts consacrée à la nouvelle version de la plate-forme Web.
Avis aux initiés: aider les développeurs CSS et UI
2022 étant une année passionnante pour les fonctionnalités CSS, nous avons pensé que c'était le bon moment pour vous faire découvrir les coulisses. J'ai rencontré Una Kravets, responsable DevRel pour l'interface utilisateur Web et les outils de développement, et Nicole Sullivan, notre responsable produit pour l'interface utilisateur Web, qui se concentre sur les API CSS et HTML. J'ai évoqué le parcours de Chrome pour aider les développeurs d'interfaces utilisateur.
Commençons par vous deux. Pouvez-vous nous en dire un peu plus sur vous ?
Nicole:Je suis responsable produit pour l'interface utilisateur Web dans Chrome. Je me concentre plus particulièrement sur les nouvelles API CSS et HTML, ainsi que sur les développeurs et les concepteurs qui créent des UI. C'est un secteur passionnant, avec la sortie d'API très importantes comme Container Requêtes, Scope et, nous l'espérons, le rythme vertical.
Una:je dirige les équipes DevRel de l'interface utilisateur Web et des 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 permettant de voir les modifications actives et les commentaires.
Ces dernières années, l'assistance de Chrome pour les développeurs d'interfaces utilisateur s'est accélérée. Pourquoi pensez-vous qu'il a fallu autant de temps pour en arriver là ? Quelles ont été les principales difficultés ?
Una:Nous avons dû démontrer l'importance de ce travail et les raisons pour lesquelles il devrait être considéré comme une priorité. Nous avons commencé par l'enquête sur l'ADN du MDN en 2019, qui considérait l'interface utilisateur comme l'un des principaux problèmes de la plate-forme. Depuis, nous avons continué à nous servir des données pour nous guider dans le MDN et dans nos propres enquêtes de satisfaction internes menées auprès des développeurs. Grâce à tout cela, nous avons pu obtenir un plus grand soutien de la direction et prioriser les travaux d'ingénierie concernant certaines des fonctionnalités les plus demandées pour les développeurs dans le domaine de l'interface utilisateur. Ces fonctionnalités sont également au cœur d'initiatives telles que Compat 2021 et Interop 2022.
Nicole:En plus d'obtenir le soutien de la direction, nous avons dû trouver le bon moyen de fournir ces API aux développeurs. Lorsque j'ai rejoint Chrome, je me suis trompée dans un projet appelé APIs en couches (ou LAPI en abrégé). Les LAPI visaient à offrir aux développeurs une expérience de déploiement de composants. Je pense toujours que c'était un excellent résultat, mais nous avons commis beaucoup d'erreurs ! Nous nous sommes d'abord concentrés sur les notifications par toast et une liste virtuelle. Les toasts sont presque impossibles à rendre accessibles et une liste virtuelle est l'un des éléments les plus difficiles à obtenir. Nos intentions étaient bonnes, mais ce projet n'aidait pas les développeurs. Nous avons donc mis fin au projet. Il est difficile d'apprendre à la dure, mais chaque erreur alimente la renaissance du CSS et du HTML qui est en train de se produire.
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êts à l'emploi, plus proche de la création d'une interface utilisateur native. Il était évident que réinventer la roue freinait les développeurs. Je n'arrive pas à compter le nombre d'onglets que j'ai créés au cours de ma carrière ! Ceci étant dit, nous avons essayé de résoudre ce problème en envoyant JavaScript avec le navigateur, ce qui était très difficile. Personne n'avait encore intégré JavaScript dans le navigateur, et il n'était pas clair de savoir comment ce code devait interagir avec le code C++ qui alimente le moteur de rendu du navigateur. Nous avons écouté les autres fournisseurs de navigateurs (merci, Mozilla !) et nous sommes sortis de cette approche. Nous avons donc pu trouver une solution bien meilleure avec Open UI. En s'appuyant sur HTML et CSS, nous nous retrouvons avec des solutions déclaratives flexibles. Comme il s'agit d'une approche déclarative, nous pouvons intégrer l'accessibilité d'une manière qui n'aurait pas été aussi facile avec JavaScript. J’ai vraiment hâte de voir où cela va nous venir. Nous travaillons à la prise en charge des éléments "selectmenu", "pop-up", "info-bulle", "nav", "accordéon", "onglets", "carrousel" et "basculement", qui sont des modèles de conception d'interface utilisateur essentiels.
Nous avons donc beaucoup appris. Je sais qu'il existe d'autres initiatives dans ce domaine, comme le CSS Houdini. Quelle est l'histoire ?
Una:Oui, la communauté Houdini nous a beaucoup appris. Il existe de nombreuses fonctionnalités Houdini utiles, mais nombre d'entre elles étaient trop basiques pour être adoptées et acceptées par une audience plus large. Nous avons réalisé que l'implémentation d'API de bas niveau ne permettait pas nécessairement de simplifier la tâche des développeurs. Au contraire, le fait de se concentrer sur les solutions et les besoins de haut niveau a permis d'obtenir la prise en charge multi-navigateurs et les aboutissements nécessaires pour faire avancer l'aiguille dans l'écosystème. Nous suivons l'évolution de la situation à 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é. Quelles sont les remarques des développeurs ?
Una:L'un des principaux problèmes des développeurs est qu'ils doivent rendre la conception identique dans tous les navigateurs. Pour résoudre ce problème, nous avons collaboré avec d'autres fournisseurs de navigateurs afin de définir des priorités et de présenter certaines des fonctionnalités les plus demandées par les développeurs. Les commentaires de la communauté ont été extrêmement positifs. De plus, grâce à un vaste effort de modification de l'architecture appelé RenderingNG, il est devenu possible d'améliorer les performances de certaines de ces fonctionnalités. Les développeurs se réjouissent de constater que ces fonctionnalités attendues depuis des années sont enfin en cours de développement et qu'elles arrivent sur tous les navigateurs.
Nicole:l'enthousiasme suscité au sein de la communauté est palpable. Vous pouvez le consulter sur Twitter. :)
Travailler avec l'écosystème s'est avéré essentiel à notre réussite pour répondre aux besoins des développeurs plus facilement. Je sais que votre équipe a beaucoup travaillé dans ce domaine. Pourriez-vous nous en dire plus ?
Nicole:Tout d'abord, je suis constamment impressionnée par les projets que les développeurs créent sur le Web. Qu'il s'agisse de la plus petite bibliothèque ou d'une bibliothèque complète sur des frameworks, les développeurs créent des choses incroyables. C'est une formidable communauté de créateurs. De plus, Chrome met tout en œuvre pour s'associer davantage à ces projets.
Par exemple, il y a quelques années, nous avons commencé à travailler avec des frameworks JavaScript tels que React et Angular. Les méta-frameworks, tels que Next, Nuxt et Gatsby L'année dernière, nous avons commencé à faire de même avec des outils d'interface utilisateur et des frameworks tels que Sass, Bootstrap et Material. J'espère que cette année à venir, nous pourrons collaborer avec GreenSock et d'autres outils qui permettent aux développeurs plus facilement. Je viens de voir Cassie Evans de GreenSock parler lors de la Smashing Conference et cela m'a vraiment enthousiaste à l'idée de travailler avec des personnes dans le domaine de l'animation.
Où voyons-nous la meilleure opportunité pour l'écosystème de l'UI Web ?
Una:En termes d'opportunités majeures, j'ai l'impression que nous n'avons fait qu'effleurer le champ des possibilités en matière d'expériences Web personnalisables. De nouvelles API telles que les requêtes de conteneur et les fonctionnalités multimédias des préférences utilisateur CSS redéfinissent la façon dont les développeurs voient le responsive design. 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 consultent leurs sites Web.
Nicole, quelles sont les prochaines étapes sur la feuille de route pour votre équipe ?
Nicole:Toutes les explorations ne donnent pas lieu à une livraison, mais il y a beaucoup de choses qui me passionnent en ce moment:
Sans oublier la première chose, nous facilitons la conception réactive basée sur les composants. Il 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 maintient la luminosité homogène d'une teinte à l'autre. 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 en cascade, le sélecteur de parent (:has), les styles cloisonnés et l'imbrication. Les développeurs en ont besoin pour créer des systèmes de conception flexibles contenant de nombreux composants réutilisables.
Faire défiler les animations liées est un autre aspect amusant. J'aime beaucoup la démonstration de Steve Gardner. Son défilement fluide et ses animations en avion sympas sont déclenchées lors du défilement. Bien que ces concepts soient amusants, il peut être difficile de les faire correctement, en particulier du point de vue de l'accessibilité. Nous effectuons donc maintenant des tests utilisateur pour l'accessibilité de la fonctionnalité.
Ce qui m'intéresse le plus, ce sont les commandes intégrées de l'interface utilisateur Web. Les développeurs créent sans cesse le même onglet, je pense que le navigateur peut les aider. À l'étape Open UI (Ouvrir l'interface utilisateur), nous travaillons sur des composants tels que le menu de sélection, le pop-up, l'info-bulle, les onglets, la navigation, l'accordéon et le bouton d'activation/de désactivation. Nous étudions comment intégrer l'accessibilité à ces primitives de navigateur afin que le Web puisse, au fil du temps, devenir accessible par défaut. Les développeurs peuvent alors se concentrer sur les problèmes plus complexes et nuancés, tandis que le navigateur prend en charge les éléments de base, comme la façon dont les onglets sont ouverts. Il faut probablement son propre message, donc je vais en rester là pour l'instant.
Enfin, nous allons continuer à investir dans l'interopérabilité entre les navigateurs. Nous avons travaillé avec des personnes de WebKit et de Gecko pour apporter de la cohérence à l'expérience des développeurs. Les développeurs nous ont clairement fait savoir qu'ils souhaitaient cette fonctionnalité.
Si vous ne l'avez pas encore fait, l'API Shared Element Transitions de l'équipe Web fluide va changer la façon dont les utilisateurs conçoivent 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émonstration.
Si les standards s'en sortent bien, on pourrait même étudier le rythme vertical cette année ! Nous pouvons nous appuyer sur LayoutNG, qui offre de nombreuses fonctionnalités.
Merci à tous les deux. Je suis sûr que toute la communauté, comme nous, est ravie du rythme renouvelé des améliorations et des fonctionnalités à venir dans le monde de l'interface utilisateur Web. Il y a encore beaucoup de choses à explorer. Par où commencer, selon vous ?
Una:la session What's new for the web platform (Nouveautés de la plate-forme Web) de Google I/O présente les points forts de nombreuses fonctionnalités présentées cette année. Adam Argyle a également rédigé un article très utile sur toutes les nouveautés et les prochaines sorties CSS. Pour l'instant, je me concentrerais sur les versions stables et n'oublierais pas les autres tâches à venir. Votre série New to the web platform (Nouveautés sur la plate-forme Web) est très intéressante à suivre. L'abonnement à la newsletter web.dev permet aussi aux développeurs boîte de réception. Et pour les développeurs qui souhaitent participer et aider dans cette démarche, rejoindre Open UI est l'un des meilleurs moyens de faciliter ce travail.
Principales mises à jour à venir
Dans le cadre de notre tradition, nous vous informons sur un changement à venir que vous devez garder à l'esprit lorsque vous créez des expériences Web.
Limiter l'âge maximal des cookies à 400 jours
- Nouveauté:lorsque les cookies sont définis avec un attribut
Expires/Max-Ageexplicite, la valeur est désormais limitée à 400 jours à l'avenir au maximum. Auparavant, il n'y avait aucune limite et les cookies pouvaient expirer plusieurs millénaires dans le futur. Cette limite vise à trouver un équilibre entre les habitudes d'utilisation courantes et le respect de la vie privée des utilisateurs. Tout site visité plus souvent que tous les 400 jours peut actualiser les cookies pour assurer la continuité du service et les utilisateurs ont la certitude que les cookies ne resteront pas longtemps sans utilisation dans leur navigateur pendant des millénaires. - Délai estimé:livraison dans Chrome 104 (stable à partir du 2 août 2022).
- Incitation à l'action pour les développeurs:les développeurs peuvent avoir besoin d'actualiser les cookies de manière proactive plus souvent qu'auparavant lorsque les utilisateurs visitent leurs sites Web. Sinon, les utilisateurs risquent d'être déconnectés 400 jours après l'enregistrement initial du cookie.
J'espère que cette édition de Chrome Dev Insider vous a plu. Si vous l'avez manqué, voici la première. Nous sommes impatients de vous en proposer davantage au cours du prochain trimestre.
D'ici là, dites-nous ce que vous pensez de cette édition de Chrome Dev Insider et ce que nous pouvons faire pour l'améliorer.
Qu'avez-vous pensé de cette édition de Chrome Dev Insider ? Donnez-nous votre avis.