Fermer

mai 4, 2021

Quel est l'avenir du CSS?


À propos de l'auteur

Drew est un ingénieur d'état-major spécialisé en frontend chez Snyk ainsi que co-fondateur de Notist et le petit système de gestion de contenu Perch . Avant cela, …
En savoir plus sur
A dessiné

Dans cet épisode, nous commençons notre nouvelle saison de Smashing Podcast avec un regard sur l'avenir du CSS. Quelles nouvelles spécifications seront bientôt disponibles dans les navigateurs? Drew McLellan s'entretient avec l'expert Miriam Suzanne pour le savoir.

Dans cet épisode, nous commençons notre nouvelle saison du Smashing Podcast avec un regard sur l'avenir de CSS. Quelles nouvelles spécifications seront bientôt disponibles dans les navigateurs? Drew McLellan s'entretient avec l'expert Miriam Suzanne pour le savoir.

Afficher les notes

Mise à jour hebdomadaire

Transcription

 Photo de Miriam Suzanne Drew McLellan: Elle est une artiste, militante, enseignant et développeur web. Elle est cofondatrice d'OddBird, un fournisseur d'applications Web personnalisées, d'outils de développement et de formation. Elle est également une experte invitée du groupe de travail CSS et une conférencière et auteure régulière partageant son expertise avec des publics du monde entier. Nous savons qu'elle connaît le CSS à la fois en amont et en aval, mais saviez-vous qu'elle a déjà remporté une course d'œufs et de cuillères en profitant d'une faille impliquant des macaronis? Mes amis fracassants, veuillez souhaiter la bienvenue à Miriam Suzanne. Salut, Miriam. Comment vas-tu?

Miriam Suzanne: Je fracasse, merci.

Drew: C'est bon à entendre. Je voulais vous parler aujourd'hui de certaines des nouveautés passionnantes qui nous attendent dans CSS. On a l'impression qu'il y a eu une petite accélération au cours des cinq dernières années de nouvelles fonctionnalités qui ont fait leur chemin dans CSS et une approche beaucoup plus ouverte et collaborative du W3C avec de vrais spécialistes indépendants comme vous, Rachel Andrew, Lea Verou et d'autres contribuant au groupe de travail en tant qu’experts invités. Est-ce que j'ai l'impression que CSS avance rapidement ou est-ce que ça semble toujours terriblement lent de l'intérieur?

Miriam: Oh, c'est les deux, je pense. Il se déplace assez vite et assez vite est encore parfois très lent car il y a tellement de considérations. Il est difficile de vraiment atterrir quelque chose partout très rapidement.

Drew: Cela doit donner l'impression qu'il y a énormément de travail en cours sur toutes sortes de choses différentes et chacune d'elles avance très, très lentement, mais quand vous regardez au niveau de l'effet cumulatif, il se passe beaucoup de choses.

Miriam: Oui, exactement, et j'ai l'impression de ne pas savoir ce qui a déclenché ce changement il y a plusieurs années, si c'était la grille et la flexbox vraiment lancées un intérêt pour ce que pourrait être le CSS, je pense, et il se passe tellement de choses. Mais c’est intéressant de regarder toutes les discussions et de regarder les spécifications. Ils se réfèrent tous les uns aux autres. CSS est très lié. Vous ne pouvez pas ajouter une fonctionnalité sans affecter toutes les autres fonctionnalités. Par conséquent, toutes ces conversations doivent garder à l'esprit toutes les autres conversations en cours. C'est vraiment un web pour essayer de comprendre comment tout a un impact sur tout le reste.

Drew: On a l'impression que le groupe de travail regarde toujours ce qu'est la pratique actuelle et voit quels trous les gens essaient de corriger, quels problèmes ils essayez de corriger, souvent avec JavaScript, et faites une grosse boule désordonnée de JavaScript. Est-ce quelque chose qui est un effort conscient ou est-ce que cela se produit naturellement?

Miriam: Je dirais que c'est très conscient. Il y a aussi une tentative consciente de prendre du recul par rapport aux idées et de dire: "D'accord, c'est ainsi que nous les avons résolues en JavaScript ou en utilisant des hacks, des solutions de contournement, peu importe." Nous pourrions simplement ouvrir le chemin de la vache, mais il existe peut-être un meilleur moyen de le résoudre une fois qu'il est natif de CSS et que vous voyez des changements sur des choses comme les variables. Lorsqu'ils passent de préprocesseurs comme Sass et Less à CSS, ils deviennent quelque chose de nouveau. Et ce n’est pas toujours le cas, parfois la transition est assez transparente, il s’agit plus simplement de prendre ce qui a déjà été conçu et de le rendre natif. Mais il y a un effort conscient pour réfléchir à cela et considérer les implications.

Drew: Ouais, parfois une petite solution de contournement cache une assez grande idée qui pourrait être plus utile en elle-même.

Miriam: Et souvent, cacher des idées qui se chevauchent. Je lisais juste un grand nombre de problèmes liés à la grille aujourd'hui parce que j'ai travaillé sur des composants réactifs, des choses comme ça, et je me suis dit: "D'accord, que se passe-t-il dans l'espace de la grille avec cela?" Et il y a tellement de propositions qui se mélangent et se chevauchent de manière vraiment intéressante. Il peut être difficile de les séparer et de dire: «D'accord, devrions-nous résoudre ces problèmes individuellement ou devons-nous les résoudre en tant que cas d'utilisation groupés? Comment faut-il aborder cela exactement? »

Drew: Je suppose que cela peut sembler, de l'extérieur, un manque de progrès frustrant lorsque vous dites:« Pourquoi cette fonctionnalité ne peut-elle pas être mise en œuvre? » C'est parce que quand vous regardez cette fonctionnalité, elle explose en quelque chose de beaucoup plus gros qui est beaucoup plus difficile à résoudre.

Miriam: Exactement.

Drew: Espérons que la résolution du plus gros problème rend toutes sortes d'autres choses possibles. J'ai passé une grande partie de ma carrière dans un poste où nous réclamions en quelque sorte quelque chose, quoi que ce soit, de nouveau à ajouter à CSS. Je suis sûr que cela vous est également familier. Il semble maintenant quasiment difficile de garder une trace de tout ce qui est nouveau, car il y a de nouvelles choses qui sortent tout le temps. Avez-vous des conseils à donner aux front-enders sur la façon dont ils peuvent suivre toutes les nouvelles arrivées dans CSS? Y a-t-il de bonnes ressources ou des choses auxquelles ils devraient prêter attention?

Miriam: Oui, il y a de grandes ressources si vous voulez vraiment un curé, une idée de ce que vous devriez regarder. Mais c’est Smashing Magazine, CSS-Tricks, tous les blogs courants, puis diverses personnes sur Twitter. Les développeurs de navigateurs ainsi que les personnes du groupe de travail ainsi que les personnes qui écrivent des articles. Je pense à Stephanie Eckles, ModernCSS. Il y a beaucoup de ressources comme ça. Je dirais également que si vous gardez un œil sur les notes de publication de différents navigateurs, elles ne sortent pas souvent, cela ne va pas spammer votre boîte de réception tous les jours. Vous verrez souvent une section dans les notes de version sur ce qu'ils ont publié en rapport avec CSS. Et généralement en termes de fonctionnalités, ce n'est qu'une ou deux choses. Vous n'allez pas être totalement submergé par toutes les nouveautés qui arrivent. Ils sortiront de six semaines à quelques mois et vous pouvez simplement garder un œil sur ce qui atterrit dans les navigateurs.

Drew: Point intéressant. Je n'avais pas pensé à regarder les notes de version du navigateur pour trouver ce genre de choses. Personnellement, je fais des efforts pour suivre les gens sur Twitter qui, je le sais, partageraient des choses, mais je trouve que des choses me manquent tout le temps sur Twitter. Il y a beaucoup de trucs sympas que je ne vois jamais.

Drew: Dans cet esprit, avant de regarder trop loin dans le futur ce qui est en cours de développement en ce moment, il y a pas mal de bouts de CSS qui ont déjà débarqué dans des navigateurs qui pourraient être nouveaux pour les gens et qui pourraient être assez utilisables dans de nombreuses circonstances. Il y a certainement des choses dont je n’étais pas au courant.

Drew: Un domaine qui me vient à l’esprit est celui des sélecteurs. Il y a cette fonction de pseudo-classe «est», par exemple. Est-ce que c'est comme un sélecteur «est» jQuery, si vous vous en souvenez? Je m'en souviens à peine.

Miriam: Je n'ai pas utilisé jQuery assez pour le dire.

Drew: Non. Maintenant, même en disant cela, c'est tellement poussiéreux dans mon esprit, je ne suis pas même sûr que c'était une chose.

Miriam: Ouais, «est» et «où», il est utile de penser à eux ensemble, ces deux sélecteurs. «Est» en quelque sorte atterri dans la plupart des navigateurs un peu avant «où», mais à ce stade, je pense que les deux sont assez bien pris en charge dans les navigateurs modernes. Ils vous permettent de lister un certain nombre de sélecteurs à l'intérieur d'un seul sélecteur de pseudo-classe. Donc, vous dites, ": est" ou ": où" et ensuite entre parenthèses, vous pouvez mettre tous les sélecteurs que vous voulez et il correspond à un élément qui correspond également aux sélecteurs à l'intérieur. Par exemple, vous pouvez dire: "Je veux styliser tous les liens à l'intérieur de n'importe quel titre." Vous pouvez donc dire «est», H1, H2, H3, H4, H5, H6, mettre une liste à l'intérieur de «est», puis, après cette liste, dire «A» une fois. Et vous n’avez pas à répéter toutes les combinaisons que vous générez là-bas. C'est une sorte de raccourci pour intégrer l'imbrication dans CSS. Vous pouvez créer ces sélecteurs imbriqués «similaires». Mais ils font aussi des choses intéressantes autour de la spécificité … Désolé, qu'alliez-vous dire?

Drew: Je suppose que c'est juste utile pour rendre votre feuille de style plus lisible et facile à maintenir si vous n'avez pas à le faire Écris à la main chaque combinaison de choses.

Miriam: Exact. L'autre chose intéressante que vous pouvez en faire est que vous pouvez commencer à combiner des sélecteurs. Vous pouvez donc dire: "Je cible uniquement quelque chose qui correspond à la fois aux sélecteurs en dehors de" est "et aux sélecteurs à l'intérieur de" est "". Il doit correspondre à toutes ces choses. » Vous pouvez donc faire correspondre plusieurs sélecteurs à la fois, ce qui est intéressant.

Drew: Où est-ce que «où» entre en jeu si c'est ce que «est» fait?

Miriam: Exact. «Où» entre en jeu en raison de la manière dont ils gèrent la spécificité. «Est» gère la spécificité en vous donnant le sélecteur entier obtient la spécificité de ce qui est la spécificité la plus élevée à l'intérieur de «est». «Est» ne peut avoir qu’une spécificité et il sera le plus élevé de tous les sélecteurs à l’intérieur. Si vous mettez un "identifiant" à l'intérieur, il aura la spécificité d'un "identifiant". Même si vous avez un "id" et une classe, deux sélecteurs, à l'intérieur de "is", cela va avoir la spécificité du "id".

Miriam: Cela revient à une spécificité plus élevée. «Où» a par défaut une spécificité nulle, ce qui est à mon avis vraiment intéressant, surtout pour les valeurs par défaut. Je veux styliser un élément audio où il a des contrôles, mais je ne veux pas y ajouter de spécificité, je veux juste dire où il est appelé pour les contrôles, où il a l'attribut contrôles, ajouter ce style à l'audio. Donc une option de spécificité zéro. Sinon, ils fonctionnent de la même manière.

Drew: D'accord. Cela signifie donc qu'avec une spécificité nulle, cela signifie que, en supposant que quelqu'un essaie de styliser ces contrôles dans l'exemple, il n'a pas à se battre contre les styles qui ont déjà été définis.

Miriam: C'est vrai, ouais. Il y a une autre chose intéressante à l'intérieur de ces deux systèmes où ils sont censés être résilients. À l'heure actuelle, si vous écrivez une liste de sélecteurs et qu'un navigateur ne comprend pas quelque chose dans cette liste de sélecteurs, il va ignorer tous les sélecteurs de la liste. Mais si vous faites cela à l'intérieur de «est» ou «où», si un sélecteur inconnu est utilisé dans une liste à l'intérieur de «est» ou «où», il devrait être résilient et les autres sélecteurs devraient toujours pouvoir correspondre. [19659012] Drew: D'accord, c'est donc cette grande propriété de CSS, que s'il ne comprend pas quelque chose, il l'ignore.

Miriam: D'accord.

Drew: ] Et donc, vous dites que s'il y a quelque chose qu'il ne comprend pas dans la liste, sautez ce qu'il ne comprend pas, mais ne jetez pas le bébé avec l'eau du bain, gardez tous les autres et appliquez

Miriam: Exactement.

Drew: C'est fascinant. Et le fait que nous ayons «est» et «où» me semble être l'un de ces exemples de quelque chose qui semble être un problème facile. "Oh, ayons un sélecteur" est "." Et puis quelqu'un dit: "Mais qu'en est-il de la spécificité?"

Miriam: Exactement.

Drew: Comment allons-nous régler cela?

Miriam: Ouais . L'autre chose intéressante est qu'elle provient de demandes d'imbrication. Les gens voulaient des sélecteurs imbriqués similaires à ce que Sass a et «est» et «où» sont, à certains égards, un demi-pas vers cela. Ils rendront les sélecteurs imbriqués plus faciles à implémenter puisque nous avons déjà un moyen de, ce qu'ils appellent les «dé-sucre».

Drew: Ce qui me semble être les coins les plus poussiéreux du HTML et du CSS, ce sont les éléments de liste et les marqueurs qu'ils ont, le blitz ou ce que vous avez. Je me souviens, probablement de retour sur Frontpage à la fin des années 90, en essayant de styliser, généralement avec des propriétés Microsoft propriétaires, pour Internet Explorer à l'époque. Mais il y a de bonnes nouvelles à l'horizon pour les amateurs de marqueurs, n'est-ce pas?

Miriam: Oui, il y a un sélecteur de marqueurs qui est vraiment génial. Nous n'avons plus besoin de supprimer les marqueurs en disant… Comment avons-nous supprimé les marqueurs? Je ne me souviens même pas. Modification du style de liste sur aucun.

Drew: Style de liste, aucun. Oui.

Miriam: Et puis les gens ajoutaient de nouveau les marqueurs en utilisant le pseudo-élément «avant». Et nous n’avons plus à faire cela. Avec le pseudo-élément marqueur, nous pouvons le styliser directement. Ce style est un peu limité, en particulier pour le moment, il va en être élargi, mais oui, c'est une fonctionnalité vraiment intéressante. Vous pouvez très rapidement changer la taille, la police, les couleurs, des choses comme ça.

Drew: Pouvez-vous aussi utiliser du contenu généré là-dedans?

Miriam: Oui. Je ne me souviens pas à quel point le contenu généré est largement pris en charge, mais vous devriez pouvoir le faire.

Drew: C'est une bonne nouvelle pour les fans de listes, je suppose. Il y a de nouveaux sélecteurs. C’est quelque chose que j’ai rencontré récemment dans le cadre d’un projet réel et j’ai commencé à utiliser l’un d’entre eux avant de me rendre compte qu’il n’était pas aussi bien pris en charge que je le pensais, car c’est nouveau. Et ce sont des sélecteurs pour aider lorsque la «mise au point» est appliquée aux éléments. Je pense que j’utilisais la «concentration intérieure» et il y en a une autre, n’est-ce pas? Il y a…

Miriam: «Focus visible».

Drew: Que font-ils?

Miriam: Les navigateurs, lorsqu'ils gèrent le «focus», ils en font décisions pour vous selon que vous cliquez avec une souris ou si vous utilisez un clavier pour naviguer. Parfois, ils affichent «focus» et parfois non, par défaut. «Focus visible» est un moyen pour nous de nous associer à cette logique et de dire: «Lorsque le navigateur pense que le focus doit être visible, pas seulement lorsqu'un élément a le focus, mais quand un élément a le focus et que le navigateur pense que le focus doit être visible , puis appliquez ces styles. » C'est utile pour avoir des anneaux de contour sur la mise au point, mais ne pas les faire apparaître lorsqu'ils ne sont pas nécessaires, lorsque vous utilisez une souris et que vous n'avez pas vraiment besoin de savoir. Vous avez cliqué sur quelque chose, vous savez que vous l'avez ciblé, vous n'avez pas besoin du style là-bas. «Focus visible» est vraiment utile pour cela. «Focus inside» vous permet de dire: «Stylisez le formulaire entier quand l'un de ses éléments a le focus», ce qui est très cool et très puissant.

Drew: Je pense que je l'utilisais dans un menu déroulant de navigation qui est-

Miriam: Oh, bien sûr.

Drew: … un champ de mines ciblé, n'est-ce pas?

Miriam: Mm-hmm (affirmatif). [19659012] Drew: Et la «concentration intérieure» s'est avérée très utile là-bas jusqu'à ce que je ne l'ait pas et que j'ai fini par écrire une charge entière de JavaScript pour recréer ce que j'avais réalisé très simplement avec CSS avant cela.

Miriam : Ouais, le danger toujours avec les nouveaux sélecteurs est de savoir comment gérer le repli.

Drew: Une chose qui me passionne vraiment est ce nouveau concept en CSS du rapport hauteur / largeur. Allons-nous pouvoir dire au revoir au hack de 56% de rembourrage supérieur?

Miriam: Oh, absolument. Je suis tellement excité de ne plus jamais utiliser ce hack. Je pense que cela arrive dans les navigateurs. Je pense qu'il est déjà disponible dans certains et devrait bientôt arriver dans d'autres. Il semble y avoir beaucoup d'excitation à ce sujet.

Drew: Certainement, c'est le problème classique, n'est-ce pas, d'avoir une vidéo ou quelque chose comme ça. Vous voulez l'afficher dans un rapport 16 par 9, mais vous voulez définir les dimensions dessus. Mais peut-être que c'est une vidéo 4 par 3 et vous devez trouver comment le faire et la mettre à l'échelle avec la droite-

Miriam: Bien, et vous voulez qu'elle soit réactive, vous voulez qu'elle se remplisse une largeur entière, mais maintenez ensuite son rapport. Ouais, les hacks pour ça ne sont pas géniaux. J'en utilise souvent une qui crée une grille, positionne le contenu généré avec un hack supérieur de remplissage, puis positionne en absolu la vidéo elle-même. C'est juste beaucoup pour le faire fonctionner comme vous le souhaitez.

Drew: Et vraisemblablement, cela va être beaucoup plus de performances pour les moteurs de mise en page à gérer et-

Miriam: Exactement. Et tout de suite, c'est en fait une raison de remettre les valeurs de largeur et de hauteur sur les éléments remplacés comme les images, en particulier, afin que même avant le chargement du CSS, le navigateur puisse déterminer quel est le bon rapport, le rapport intrinsèque, même avant le l'image se charge et l'utilise dans le CSS. Nous avions l'habitude de supprimer tout cela parce que nous voulions des pourcentages à la place et maintenant il est bon de les remettre.

Drew: Oui, j'allais dire que lorsque la conception Web réactive est arrivée, nous les avons supprimées. . Mais je pense que nous avons perdu quelque chose dans le processus, n'est-ce pas, de donner au navigateur cette information importante sur l'espace à réserver?

Miriam: Oui, et cela est lié à ce que Jen Simmons a parlé récemment avec la conception Web intrinsèque. L'idée avec un design réactif était essentiellement de supprimer tout dimensionnement intrinsèque et de le remplacer par des pourcentages. Et maintenant, les outils dont nous disposons, flex et grid, sont en fait conçus pour fonctionner avec des tailles intrinsèques et il est utile de tous les remettre en place et nous pouvons toujours les remplacer si nécessaire. Mais avoir ces tailles intrinsèques est utile et nous les voulons.

Drew: Grid, vous l'avez mentionné, j'ai en quelque sorte révolutionné la façon dont nous pensons à la mise en page sur le Web. Mais cela a toujours été un peu tempéré par le fait que nous n’avons pas obtenu de sous-grille en même temps. Rappelez-nous, si vous voulez, en quoi consiste la sous-grille et où en sommes-nous maintenant avec le soutien?

Miriam: Ouais. Grid établit un parent de grille, puis toutes ses dispositions enfants sur cette grille. Et la sous-grille vous permet de les imbriquer et de dire: "D'accord, je veux que les petits-enfants fassent partie de la grille des grands-parents." Même si mon arbre DOM est assez imbriqué, je peux faire remonter des éléments dans la grille parent, ce qui est utile. Mais c'est particulièrement utile lorsque vous pensez au fait que CSS en général et CSS Grid en particulier font que les va-et-vient de certaines parties de la mise en page sont déterminés en fonction de la largeur disponible du conteneur. Ils sont contextuels, ils sont à l’extérieur. Mais alors aussi, certaines parties de celui-ci sont déterminées par la taille des enfants, la taille du contenu, nous avons donc cette constante dans les deux sens dans CSS entre si le contexte est en contrôle ou si le contenu est en contrôle de la mise en page . Et souvent, ils sont liés de manière très complexe. Ce qui est le plus intéressant à propos de la sous-grille, c'est que cela permettrait au contenu des éléments de la grille de contribuer à leur redimensionnement à la grille des grands-parents et cela rendrait encore plus explicite les allers-retours entre le contenu et le contexte.

Drew: problème qui a été rencontré par les requêtes de conteneur? Parce que vous ne pouvez pas vraiment parler de l’avenir du CSS et demander aux concepteurs et aux développeurs ce qu’ils veulent en CSS sans que quelqu'un dise deux minutes: «Ah, les requêtes de conteneur, c’est ce que nous voulons». Est-ce un problème similaire de cette poussée et de cette traction des deux contextes différents pour déterminer combien d'espace il y a?

Miriam: Oui, ils sont tous les deux liés à cette question de contenu de contexte. Subgrid n’a pas à faire face aux mêmes problèmes. Subgrid fonctionne réellement. Il est en fait capable de transmettre ces valeurs dans les deux sens car vous ne pouvez pas modifier le contenu en fonction du contexte. Nous avons en quelque sorte coupé cette boucle. Et le problème avec les requêtes de conteneur a toujours été qu'il y a une boucle infinie potentielle où si nous permettons au contenu d'être stylé en fonction de son contexte explicitement, et vous pourriez dire: «Quand j'ai moins de 500 pixels disponibles, faites-le de 600 pixels de large . » Vous pouvez créer cette boucle dans laquelle cette taille modifie la taille du parent, ce qui change si la requête de conteneur s'applique et indéfiniment. Et si vous êtes dans l’univers Star Trek, le robot explose. Vous obtenez cette boucle infinie. Le problème avec les requêtes de conteneur que nous avons dû résoudre est de savoir comment couper cette boucle.

Drew: Les requêtes de conteneur sont l'une des fonctionnalités CSS pour lesquelles vous êtes l'un des éditeurs, est-ce exact ?

Miriam: Ouais.

Drew: Donc, le concept général est comme une requête multimédia, où nous examinons la taille d'une fenêtre, je suppose, et changeons le CSS en fonction de celui-ci . Les requêtes de conteneur doivent faire cela, mais en regardant la taille d'un élément conteneur. Je suis donc une image de héros sur une page, combien d’espace ai-je?

Miriam: Exact. Ou je suis un élément de la grille dans une piste. Combien d'espace ai-je dans cette piste? Ouais.

Drew: Cela semble très difficile à résoudre. Sommes-nous près d'une solution pour les requêtes de conteneurs maintenant?

Miriam: Nous sommes très près d'une solution maintenant.

Drew: Hourra!

Miriam: Il y a encore des cas extrêmes qui nous n'avons pas résolu, mais à ce stade, nous faisons un prototypage pour trouver ces cas extrêmes et voir si nous pouvons tous les résoudre. Mais les prototypes avec lesquels nous avons joué jusqu'à présent, étonnamment, ne fonctionnent que dans la majorité des cas, ce qui a été si amusant à voir. Mais c’est une longue histoire. C'est un peu ce truc avec… Comme si nous obtenons «est» parce que c'est à mi-chemin de l'imbrication. Et il y a eu tellement de travail au cours des 10 dernières années. Ce qui ressemble à ce que le groupe de travail CSS n'obtient nulle part sur les requêtes de conteneur a en fait implémenté toutes les demi-étapes dont nous aurions besoin pour arriver ici. Je suis venu à bord pour aider avec cette dernière poussée, mais il y a eu tellement de travail pour établir le confinement et tous ces autres concepts sur lesquels nous nous appuyons maintenant pour rendre les requêtes de conteneurs possibles.

Drew: C'est vraiment passionnant. Y a-t-il maintenant une sorte de chronologie que nous pourrions nous attendre à ce qu’ils entrent dans les navigateurs?

Miriam: C’est difficile à dire exactement. Tous les navigateurs n'annoncent pas leurs projets. Certains plus que d'autres. C’est difficile à dire, mais tous les navigateurs semblent enthousiasmés par l’idée. Il existe actuellement un prototype fonctionnel dans Chrome Canary avec lequel les gens peuvent jouer et nous recevons des commentaires pour apporter des modifications. Je travaille sur les spécifications. J'imagine faire face à une partie de la complexité dans les cas extrêmes. Il faudra un certain temps pour que la spécification se solidifie vraiment, mais je pense que nous avons une proposition assez solide dans l'ensemble et j'espère que d'autres navigateurs commenceront bientôt à comprendre. Je sais que le confinement, en demi-étape, n'est déjà pas implémenté partout, mais je sais qu'Igalia s'efforce de s'assurer qu'il existe une prise en charge du confinement entre les navigateurs et que cela devrait permettre à chaque navigateur d'intensifier et de faire les requêtes de conteneur plus facilement.

Drew: Igalia est un cas intéressant, n'est-ce pas? Ils ont été impliqués dans une grande partie de l'implémentation sur Grid au départ, n'est-ce pas?

Miriam: Oui. Je crois comprendre qu'ils ont été embauchés par Bloomberg ou quelqu'un qui voulait vraiment des grilles. Igalia est vraiment intéressant. C'est une entreprise qui contribue à tous les navigateurs.

Drew: Il semble que ce soit une sorte de valeur aberrante. Toutes les différentes parties qui travaillent sur CSS sont principalement, comme vous vous en doutez, principalement des fournisseurs de navigateurs. Mais oui, ils sont là comme une sorte de développeur plus indépendant, ce qui est très intéressant.

Miriam: Un fournisseur de navigateur.

Drew: Oui. Absolument. Une autre chose dont je voulais vous parler est ce concept qui m'a complètement tordu l'esprit pendant que je commençais à y réfléchir. C’est ce concept de couches en cascade. Je pense que beaucoup de développeurs connaissent peut-être les différents aspects de la cascade CSS, la spécificité, l'ordre des sources, l'importance, l'origine. Est-ce que ce sont les principaux? Que sont les couches en cascade? Est-ce un autre élément de la cascade?

Miriam: Ouais. C'est un autre élément qui ressemble beaucoup à ceux-là. Je pense que souvent lorsque nous parlons de cascade, beaucoup de gens la considèrent principalement comme une spécificité. Et d'autres choses sont liées à cela. Les gens considèrent l'importance comme une spécificité plus élevée, les gens pensent que l'ordre des sources est une spécificité inférieure. Cela a du sens car, en tant qu'auteurs, nous passons la plupart de notre temps dans la spécificité.

Miriam: Mais ce sont des choses séparées et l'importance est plus directement liée aux origines. Cette idée d'où viennent les styles. Viennent-ils d'auteurs comme nous ou de navigateurs, les styles par défaut, ou viennent-ils d'utilisateurs? Donc, trois origines de base et celles-ci se superposent de différentes manières. Et puis, il est important de retourner l’ordre pour qu’il y ait un certain équilibre de contrôle. Nous pouvons remplacer tout le monde par défaut, mais les utilisateurs et les navigateurs peuvent dire: «Non, c'est important. Je veux reprendre le contrôle. » Et ils gagnent.

Miriam: Pour nous, l'importance agit un peu comme une couche de spécificité parce que les styles d'auteur normaux et les styles d'auteur importants sont juste à côté de l'autre, il est donc logique que nous les considérions de cette façon. Mais je regardais cela et je pensais que la spécificité est cette tentative de dire… C'est une heuristique. Cela signifie que c'est une supposition intelligente. Et la supposition est basée sur le fait que nous pensons que plus un élément est ciblé de manière étroite, plus vous vous en souciez probablement. Probablement. C’est une supposition, ce ne sera pas parfait, mais cela nous met à mi-chemin. Et c'est un peu vrai. Plus nous ciblons quelque chose de près, probablement plus nous nous en soucions, donc les styles plus ciblés l'emportent sur les styles moins ciblés.

Miriam: Mais ce n'est pas toujours vrai. Parfois, cela s'effondre. Et ce qui se passe, c'est qu'il y a trois niveaux de spécificité. Il y a des identifiants, des classes et des attributs, et il y a des éléments eux-mêmes. De ces trois couches, nous contrôlons l'une d'entre elles complètement. Classes et attributs, nous pouvons faire tout ce que nous voulons avec eux. Ils sont réutilisables, ils sont personnalisables. Ce n’est pas le cas pour l’une ou l’autre des deux autres couches. Une fois que les choses se compliquent, nous finissons souvent par essayer de faire toute notre gestion en cascade dans cette seule couche, puis nous nous mettons en colère, en levant les mains et en ajoutant de l'importance. Ce n’est pas idéal.

Miriam: Et j’étais en train de regarder les origines parce que j’allais faire des vidéos pour enseigner la cascade dans son intégralité, et j’ai pensé que c’était en fait assez intelligent. En tant qu'auteurs, nous avons souvent des styles qui viennent de différents endroits et représentent des intérêts différents. Et si nous pouvions les superposer de la même manière que nous pouvons superposer les styles d'auteur, les styles utilisateur et les styles de navigateur. Mais à la place, que se passe-t-il s'ils sont… Voici le système de conception, voici les styles des composants eux-mêmes, voici les abstractions générales. Et parfois, nous avons de larges abstractions qui sont étroitement ciblées et parfois nous avons des utilitaires de composants hautement reproductibles ou quelque chose qui doit avoir beaucoup de poids. Et si nous pouvions les mettre explicitement dans des couches nommées?

Miriam: Jen Simmons m'a encouragé à soumettre cela au groupe de travail et ils étaient enthousiastes à ce sujet et les spécifications ont évolué très rapidement. Au début, nous craignions tous de nous retrouver dans une situation d'index z. Couche 999 000 quelque chose. Et dès que nous avons commencé à mettre en place la syntaxe, nous avons constaté que ce n’était pas difficile à éviter. J’ai été très excité de voir cela se concrétiser. Je pense que c'est une excellente syntaxe que nous avons.

Drew: Quelle forme prend la syntaxe, en gros? Je sais qu'il est difficile de prononcer le code, n'est-ce pas?

Miriam: C'est une règle «@» appelée «@layer». Il existe en fait deux approches. Vous pouvez également utiliser, nous ajoutons une fonction à la syntaxe «@import» afin que vous puissiez importer une feuille de style dans une couche, par exemple importer Bootstrap dans ma couche de cadre. Mais vous pouvez également créer ou ajouter des couches à l'aide de la règle «@layer». Et il s’agit simplement de "@layer", puis du nom du calque. Et les couches sont empilées dans l'ordre où elles ont été introduites pour la première fois, ce qui signifie que même si vous importez des feuilles de style de partout et que vous ne savez pas dans quel ordre elles vont se charger, vous pouvez, en haut de votre document, dites: "Voici les calques que je prévois de charger, et voici l'ordre dans lequel je les veux." Et puis, plus tard, lorsque vous ajoutez réellement des styles dans ces calques, ils sont déplacés dans l'ordre d'origine. C’est aussi une façon de dire: «Ignorez l’ordre source ici. Je veux pouvoir charger mes styles dans n'importe quel ordre et toujours contrôler comment ils doivent se substituer les uns aux autres. »

Drew: Et à sa manière, avoir une liste, en haut, de toutes ces différentes couches est auto-documentée aussi, parce que quiconque accède à cette feuille de style peut voir l'ordre de tous les calques.

Miriam: Et cela signifie aussi que, disons, Bootstrap pourrait partir et utiliser beaucoup de couches et vous pouvez extraire ces couches de Bootstrap. Ils contrôlent la relation entre leurs propres couches, mais vous pouvez contrôler la manière dont ces différentes couches de Bootstrap sont liées à votre document. Alors, quand Bootstrap devrait-il l'emporter sur vos couches et quand vos couches devraient-elles l'emporter sur Bootstrap? Et vous pouvez commencer à être très explicite sur ces choses sans jamais lancer le drapeau «important».

Drew: Ces calques d'une feuille de style importée, si elle avait ses propres calques, se mélangeraient-ils tous simplement au moment où la feuille de style a été ajoutée?

Miriam: Par défaut, à moins que vous n'ayez déjà défini ailleurs comment ordonner ces calques. Donc encore, votre ordre initial des couches serait prioritaire.

Drew: Si Bootstrap, par exemple, avait documenté leurs couches, seriez-vous en mesure d'en cibler une en particulier et de la mettre dans votre pile de couches pour la modifier?

Miriam: Oui.

Drew: Ce n'est donc pas une chose encapsulée qui bouge en une seule fois. Vous pouvez réellement le séparer et…

Miriam: Cela dépendrait… Nous avons plusieurs idées ici. We’ve built in the ability to nest layers that seemed important if you were going to be able to import into a layer. You would have to then say, “Okay, I’ve imported all of Bootstrap into a layer called frameworks,” but they already had a layer called defaults and a layer called widgets or whatever. So then I want a way to target that sublayer. I want to be able to say “frameworks widgets” or “frameworks defaults” and have that be a layer. So we have a syntax for that. We think that all of those would have to be grouped together. You couldn’t pull them apart if they’re sublayered. But if Bootstrap was giving you all those as top level layers, you could pull them in at the top level, not group them. So we have ways of doing both grouping or splitting apart.

Drew: And the fact that you can specify a layer that something is imported into that doesn’t require any third-party script to know about layers or have implemented it, presumably, it just pulls that in at the layer you specify.

Miriam: Right.

Drew: That would help with things pretty much like Bootstrap and that sort of thing, but also just with the third party widgets you’re then trying to fight with specificity to be able to re-style them and they’re using id’s to style things and you want to change the theme color or something and you having to write these very specific… You can just change the layer order to make sure that your layers would win in the cascade.

Miriam: Yup. That’s exactly right. The big danger here is backwards compatibility. It’s going to be a rough transition in some sense. I can’t imagine any way of updating the cascade or adding the sort of explicit rules to the cascade without some backwards compatibility issues. But older browsers are going to ignore anything inside a layer rule. So that’s dangerous. This is going to take some time. I think we’ll get it implemented fairly quickly, but then it will still take some time before people are comfortable using it. And there are ways to polyfill it particularly using “is.” The “is selector gives us a weird little polyfill that we’ll be able to write. So people will be able to use the syntax and polyfill it, generate backwards-compatible CSS, but there will be some issues there in the transition.

Drew: Presumably. And you’re backwards-compatible to browsers that support “is.”

Miriam: That’s right. So it gets us a little farther, but not… It’s not going to get us IE 11.

Drew: No. But then that’s not necessarily a bad thing.

Miriam: Yeah.

Drew: It feels like a scoping mechanism but it’s not a scoping mechanism, is it, layers? It’s different because a scope is a separate thing and is actually a separate CSS feature that there’s a draft in the works for, is that right?

Miriam: Yeah, that’s another one that I’m working on. I would say, as with anything in the cascade, they have sort of an overlap. Layers overlap with specificity and both of them overlap with scope.

Miriam: The idea with scope, what I’ve focused on, is the way that a lot of the JavaScript tools do it right now. They create a scope by generating a unique class name, and then they append that class name to everything they consider within a scope. So if you’re using “view” that’s everything within a view component template or something. So they apply it to every element in the HTML that’s in the scope and then they also apply it to every single one of your selectors. It takes a lot of JavaScript managing and writing these weird strings of unique ids.

Miriam: But we’ve taken the same idea of being able to declare a scope using an “@scope” rule that declares not just the root of the scope, not just this component, but also the lower boundaries of that scope. Nicole Sullivan has called this “donut scope”, the idea that some components have other components inside of them and the scope only goes from the outer boundaries to that inner hole and then other things can go in that hole. So we have this “@scope” rule that allows you to declare both a root selector and then say “to” and declare any number of lower boundaries. So in a tab component it might be “scope tabs to tab contents” or something so you’re not styling inside of the content of any one tab. You’re only scoping between the outer box and that inner box that’s going to hold all the contents.

Drew: So it’s like saying, “At this point, stop the inheritance.”

Miriam: Not exactly, because it doesn’t actually cut off inheritance. The way I’m proposing it, what it does is it just narrows the range of targeted elements from a selector. So any selector you put inside of the scope rule will only target something that is between the root and the lower boundaries and it’s a targeting issue there. There is one other part of it that we’re still discussing exactly how it should work where, the way I’ve proposed it, if we have two scopes, let’s call them theme scopes. Let’s say we have a light theme and a dark theme and we nest them. Given both of those scopes, both of them have a link style, both of those link styles have the same specificity, they’re both in scopes. We want the closer scope to win in that case. If I’ve got nested light and dark and light and dark, we want the closest ancestor to win. So we do have that concept of proximity of a scope.

Drew: That’s fascinating. So scopes are the scope of the targeting of a selector. Now, I mentioned this idea of inheritance. Is there anything in CSS that might be coming or might exist already that I didn’t know about that will stop inheritance in a nice way without doing a massive reset?

Miriam: Well, really, the way to stop inheritance is with some sort of reset. Layers would actually give you an interesting way to think about that because we have this idea of… There’s already a “revert” rule. We have an “all” property, which sets all properties, every CSS property, and we have a “revert” rule, which reverts to the previous origin. So you can say “all revert” and that would stop inheritance. That would revert all of the properties back to their browser default. So you can do that already.

Miriam: And now we’re adding “revert layer”, which would allow you to say, “Okay I’m in the components layer. Revert all of the properties back to the defaults layer.” So I don’t want to go the whole way back to the browser defaults, I want to go back to my own defaults. We will be adding something like that in layers that could work that way.

Miriam: But a little bit, in order to stop inheritance, in order to stop things from getting in, I think that belongs more in the realm of shadow DOM encapsulation. That idea of drawing hard boundaries in the DOM itself. I’ve tried to step away from that with my scope proposal. The shadow DOM already is handling that. I wanted to do something more CSS-focused, more… We can have multiple overlapping scopes that target different selectors and they’re not drawn into the DOM as hard lines.

Drew: Leave it to someone else, to shadow DOM. What stage are these drafts at, the cascade layers and scope? How far along the process are they?

Miriam: Cascade layers, there’s a few people who want to reconsider the naming of it, but otherwise, the spec is fairly stable and there’s no other current issues open. Hopefully, that will be moving to candidate recommendation soon. I expect browsers will at least start implementing it later this year. That one is the farthest along because for browsers, it’s very much the easiest to conceptualize and implement, even if it may take some time for authors to make the transition. That one is very far along and coming quickly.

Miriam: Container queries are next in line, I would say. Since we already have a working prototype, that’s going to help a lot. But actually defining all of the spec edge cases… Specs these days are, in large part, “How should this fail?” That’s what we got wrong with CSS 1. We didn’t define the failures and so browsers failed differently and that was unexpected and hard to work with. Specs are a lot about dealing with those failures and container queries are going to have a lot of those edge cases that we have to think through and deal with because we’re trying to solve weird looping problems. It’s hard to say on that one, because we both have a working prototype ahead of any of the others, but also it’s going to be a little harder to spec out. I think there’s a lot of interest, I think people will start implementing soon, but I don’t know exactly how long it’ll take.

Miriam: Scope is the farthest behind of those three. We have a rough proposal, we have a lot of interest in it, but very little agreement on all the details yet. So that one is still very much in flux and we’ll see where it goes.

Drew: I think it’s amazing, the level of thought and work the CSS Working Group are putting into new features and the future of CSS. It’s all very exciting and I’m sure we’re all very grateful for the clever folks like yourself who spend time thinking about it so that we get new tools to use. I’ve been learning all about what’s coming down the pike in CSS, what have you been learning about lately, Miriam?

Miriam: A big part of what I’m learning is how to work on the spec process. It’s really interesting and I mean the working group is very welcoming and a lot of people there have helped me find my feet and learn how to think about these things from a spec perspective. But I have a long ways to go on that and learning exactly how to write the spec language and all of that. That’s a lot in my mind.

Miriam: Meanwhile, I’m still playing with grids and playing with custom properties. And while I learned both of those, I don’t know, five years ago, there’s always something new there to discover and play with, so I feel like I’m never done learning them.

Drew: Yup. I feel very much the same. I feel like I’m always a beginner when it comes to a lot of CSS.

Drew: If you, dear listener, would like to hear more from Miriam, you can find her on Twitter where she’s @MiriSuzanne, and her personal website is miriamsuzanne.com. Thanks for joining us today, Miriam. Do you have any parting words?

Miriam: Thank you, it’s great chatting with you.

Smashing Editorial" width="35" height="46" loading="lazy" decoding="async(il)




Source link