Le groupe de travail CSS au TPAC : quoi de neuf dans CSS ?

La semaine dernière, j'ai assisté au W3C TPAC ainsi qu'à la réunion du groupe de travail CSS. Diverses modifications ont été apportées aux spécifications et des discussions ont eu lieu qui, à mon avis, intéressent les concepteurs et les développeurs Web. Dans cet article, j'expliquerai un peu ce qui se passe au TPAC, et montrerai quelques exemples et démos des choses dont nous avons discuté au TPAC pour CSS en particulier.

Qu'est-ce que le TPAC ?

TPAC est la semaine des réunions techniques plénières / du comité consultatif du W3C. Une chance pour tous les différents groupes de travail qui font partie du W3C de se réunir sous un même toit. L'événement se déroule chaque année dans une partie différente du monde, cette année il s'est tenu à Lyon, en France. Au TPAC, les groupes de travail tels que le groupe de travail CSS ont leurs propres réunions, tout comme nous le faisons à d'autres moments de l'année. Cependant, parce que nous sommes tous dans un même bâtiment, cela signifie que des personnes d'autres groupes peuvent plus facilement venir en tant qu'observateurs, et les intérêts des groupes de travail croisés peuvent être discutés.

Les participants au TPAC sont généralement membres d'un ou plusieurs des groupes de travail, travaillant sur les technologies du W3C. Ils seront soit des représentants d'une organisation membre, soit des experts invités. Comme pour toutes les autres réunions des groupes de travail du W3C, les procès-verbaux de toutes les discussions tenues au TPAC seront librement disponibles, généralement sous forme de journaux IRC écrits pendant les réunions.

Le groupe de travail CSS

Le groupe de travail CSS se réunit en personne au TPAC et à au moins deux autres occasions au cours de l'année ; cela s'ajoute à nos appels téléphoniques hebdomadaires. Lors de toutes nos réunions, les différentes questions soulevées sur le cahier des charges sont discutées, et des décisions prises. Certains problèmes sont conservés pour des discussions en face à face en raison des avantages de pouvoir les avoir avec l'ensemble du groupe, ou simplement de pouvoir tous se déplacer sur un tableau blanc ou voir une démo à l'écran.

Lorsqu'un problème est discuté lors d'une réunion (que ce soit en face à face ou par téléconférence), le problème GitHub concerné est mis à jour avec le compte rendu de la discussion. Cela signifie que si vous souhaitez suivre un problème, vous pouvez le suivre et voir quand il est mis à jour. Les procès-verbaux complets de l'IRC sont également publiés sur la liste de diffusion de style www.

Voici une sélection des sujets dont nous avons discuté et qui, je pense, vous intéresseront le plus.

Barres de défilement CSS

La spécification CSS Scrollbars cherche à donner un moyen standard de styliser la taille et la couleur des barres de défilement. Si vous avez Firefox Nightly, vous pouvez le tester. Pour voir les exemples ci-dessous, utilisez Firefox Nightly et activez les drapeaux layout.css.scrollbar-width.enabled et layout.css.scrollbar-color.enabled en visitant https://about:config dans Firefox Nightly.

La spécification nous donne deux nouvelles propriétés : scrollbar-width et scrollbar-color . La propriété scrollbar-width peut prendre une valeur de auto , thin , none ou length (telle que 1em ). Il semble que la valeur de length puisse être supprimée de la spécification. Comme vous pouvez l'imaginer, il serait possible pour un développeur Web de créer une barre de défilement très inutilisable en jouant avec la largeur, il peut donc être préférable de laisser le navigateur décider de la largeur exacte qui a du sens, mais plutôt d'afficher mince ou épais barres de défilement. Firefox n'a pas implémenté l'option de longueur.

Si vous utilisez auto comme valeur, le navigateur utilisera les barres de défilement par défaut : thin vous donnera une barre de défilement fine, et none n'affichera aucune barre de défilement visible (mais l'élément pourra toujours défiler).

Dans un navigateur prenant en charge les barres de défilement CSS, vous pouvez le voir en action dans la démo :

La propriété scrollbar-color traite — comme vous vous en doutez — les couleurs de la barre de défilement. Une barre de défilement comporte deux parties que vous pouvez colorer indépendamment :

• pouce
  Le curseur qui se déplace de haut en bas lorsque vous faites défiler.
• Piste
  L'arrière-plan de la barre de défilement.

Les valeurs de la propriété scrollbar-color sont auto , dark , light et <color> <color> .

L'utilisation de auto comme valeur de mot-clé vous donnera les couleurs de la barre de défilement par défaut pour ce navigateur, dark fournira une barre de défilement sombre, soit dans le mode sombre de cette plate-forme, soit dans un mode sombre personnalisé, light le mode clair de la plate-forme ou un mode clair personnalisé .

Pour définir vos propres couleurs, vous ajoutez deux couleurs comme valeur séparées par un espace. La première couleur sera utilisée pour le pouce et la seconde pour la piste . Vous devez veiller à ce qu'il y ait suffisamment de contraste entre les couleurs, sinon la barre de défilement peut être difficile à utiliser pour certaines personnes.

Dans un navigateur prenant en charge les barres de défilement CSS, vous pouvez voir ceci dans la démo :

Unités de rapport d'aspect

Nous utilisons le padding hack en CSS pour obtenir des boîtes de rapport d'aspect depuis un certain temps, cependant, avec l'avènement de Grid Layout et de meilleures façons de dimensionner le contenu, avoir un véritable moyen de faire des rapports d'aspect en CSS est devenu un besoin plus pressant .

Il y a deux problèmes soulevés sur GitHub qui se rapportent à cette exigence :

• Unités de rapport d'aspect nécessaires
• Ratio d'aspect.

Il existe maintenant un projet de spécification dans le niveau 4 du dimensionnement CSS, et la décision de la réunion a été que cela nécessitait une discussion plus approfondie sur GitHub avant que toute décision puisse être prise. Donc, si cela vous intéresse ou si vous avez d'autres cas d'utilisation, le groupe de travail CSS serait intéressé par vos commentaires sur ces questions.

La pseudo-classe fonctionnelle :where()

L'année dernière, le CSSWG a décidé d'ajouter une pseudo-classe qui agissait comme :matches() mais avec une spécificité nulle, facilitant ainsi le remplacement sans avoir besoin de gonfler artificiellement la spécificité des éléments ultérieurs pour remplacer quelque chose dans une feuille de style par défaut.

La pseudo-classe :matches() est peut-être nouvelle pour vous car il s'agit d'un sélecteur de niveau 4, cependant, elle vous permet de spécifier un groupe de sélecteurs auxquels appliquer du CSS. Par exemple, vous pourriez écrire :

 .foo a:hover, pa:hover { color: green; }

Ou avec :matches()

 :matches(.foo, p) a:hover { color: green; }

Si vous avez déjà eu une grosse pile de sélecteurs juste pour définir les mêmes règles, vous verrez à quel point cela sera utile. Le CodePen suivant utilise les noms préfixés de webkit-any et -moz-any pour illustrer la fonctionnalité matches() . Vous pouvez également en savoir plus sur matches() sur MDN.

Là où nous faisons souvent ce genre d'empilement de sélecteurs, et donc là où :matches() sera le plus utile, c'est dans une sorte de feuille de style initiale par défaut. Cependant, nous devons ensuite faire attention lors de l'écrasement de ces valeurs par défaut à ce que tout écrasement soit effectué de manière à garantir qu'il est plus spécifique que les valeurs par défaut. C'est pour cette raison qu'une version à spécificité zéro a été proposée.

La question qui a été discutée lors de la réunion concernait la dénomination de cette pseudo-classe, vous pouvez voir la résolution finale ici, et si vous vous demandez pourquoi divers noms ont été exclus, jetez un œil au fil de discussion complet. Nommer des choses en CSS est très difficile, car nous allons tous devoir vivre avec ça pour toujours ! Après de nombreux débats, le groupe a voté et a décidé d'appeler ce sélecteur :where() .

Depuis la réunion, et pendant que j'écrivais ce post, une suggestion a été émise pour renommer matches() en is() . Jetez un œil au problème et commentez si vous avez des sentiments forts de toute façon !

Raccourcis logiques pour les marges et le rembourrage

Au sujet de la dénomination des choses, j'ai écrit sur les propriétés et les valeurs logiques ici sur Smashing Magazine dans le passé, jetez un œil à "Comprendre les propriétés et les valeurs logiques". Ces propriétés et valeurs fournissent des mappages relatifs au flux. Cela signifie que si vous utilisez des modes d'écriture autres qu'un mode d'écriture horizontal de haut en bas, comme l'anglais, des choses comme les marges et le remplissage, les largeurs et la hauteur suivent la direction du texte et ne sont pas liées aux dimensions physiques de l'écran.

Par exemple, pour les marges physiques, nous avons :

• margin-top
• margin-right
• margin-bottom
• margin-left

Les mappages logiques pour ceux-ci (en supposant horizontal-tb) sont :

• margin-block-start
• margin-inline-end
• margin-block-end
• margin-inline-start

Nous pouvons avoir deux raccourcis de valeur. Par exemple, pour définir à la fois margin-block-start et margin-block-end comme raccourci, nous pouvons utiliser margin-block: 20px 1em . La première valeur représentant l'arête de départ dans la dimension de bloc, la seconde valeur l'arête de fin dans la dimension de bloc.

Cependant, nous rencontrons un problème en ce qui concerne la margin de sténographie à quatre valeurs . Ce nom de propriété est utilisé pour les marges physiques - comment dénotons-nous la version logique à quatre valeurs ? Diverses choses ont été suggérées, y compris un commutateur en haut du fichier :

 @mode "logical";

Ou, pour utiliser un bloc qui ressemble un peu à une requête multimédia :

 @mode (flow-mode: relative) { }

Ensuite, diverses suggestions de modificateurs de mots clés, en utilisant un caractère de ponctuation ou en créant un tout nouveau nom de propriété :

 margin: relative 1em 2em 3em 4em; margin: 1em 2em 3em 4em !relative; margin-relative: 1em 2em 3em 4em; ~margin: 1em 2em 3em 4em;

Vous pouvez lire le numéro pour voir les différentes choses qui sont envisagées. Les problèmes abordés étaient que, bien que la version logique puisse finir par être généralement la version par défaut, vous souhaiterez parfois que les choses se rapportent à la géométrie de l'écran; nous devons pouvoir avoir les deux options dans une seule feuille de style. Avoir un paramètre @mode en haut du CSS peut prêter à confusion ; cela échouerait si quelqu'un devait copier et coller un morceau de la feuille de style.

Ma préférence est d'avoir une sorte de valeur de mot-clé. De cette façon, si vous regardez la règle, vous pouvez voir exactement quel mode est utilisé, même si cela semble un peu inélégant. C'est le genre de choses qu'un préprocesseur pourrait gérer pour vous ; si vous vouliez en effet que toutes vos propriétés et valeurs utilisent les versions logiques.

Nous n'avons pas réussi à résoudre le problème, donc si vous avez des idées sur ce qui pourrait être le mieux, ou si vous voyez des problèmes avec eux que nous n'avons pas décrits, veuillez commenter le problème sur GitHub.

Discussion sur les tests de la plate-forme Web

Lors de la réunion du groupe de travail CSS, puis lors de la journée plénière technique de style non-conférence, j'ai participé à des discussions sur la manière d'impliquer davantage de personnes dans l'écriture de tests pour les spécifications CSS. Le projet Web Platform Tests vise à fournir des tests pour l'ensemble de la plateforme web. Ces tests aident ensuite les fournisseurs de navigateurs à vérifier si leur navigateur est correct quant aux spécifications. Au sein du groupe de travail CSS, l'objectif est que toute modification normative d'une spécification ayant atteint le statut de recommandation candidate (CR) soit accompagnée d'un test. Cela a du sens car une fois qu'une spécification est en CR, nous demandons aux navigateurs de mettre en œuvre cette spécification et de fournir des commentaires. Ils doivent savoir si quelque chose dans la spécification change afin de pouvoir mettre à jour leur code.

Le problème est que nous avons très peu de personnes qui écrivent des spécifications, donc le fait que les rédacteurs de spécifications aient à écrire tous les tests ralentira la progression du CSS. Nous aimerions voir d'autres personnes écrire des tests, car c'est un moyen de contribuer à la plate-forme Web et d'acquérir une connaissance approfondie du fonctionnement des spécifications. Nous nous sommes donc réunis pour réfléchir à la façon dont nous pourrions encourager les gens à participer à l'effort. J'ai écrit sur ce sujet dans le passé; si l'idée d'écrire des tests pour la plateforme vous intéresse, jetez un œil à mon article 24 Ways sur "Tester la plateforme Web".

Au travail !

TPAC a considérablement ajouté à ma liste de choses à faire personnelle. Cependant, j'ai pu obtenir des conseils sur l'édition des spécifications, l'écriture des tests et proposer un plan pour ramener la spécification de la disposition multi-colonnes - dont je suis le co-éditeur - au statut CR. En tant que personne qui n'aime pas les réunions, j'ai pu constater à quel point ces réunions en face à face sont précieuses pour la plate-forme Web, donnant à ceux d'entre nous qui y contribuent une chance de partager les connaissances que nous développons individuellement. Je pense qu'il est important de prendre ensuite ces connaissances et de les partager en dehors du groupe afin d'aider davantage de personnes à s'impliquer dans le développement et l'utilisation de la plate-forme.

Si vous êtes intéressé par le fonctionnement du groupe de travail CSS et par la façon dont le nouveau CSS est inventé et se retrouve dans les navigateurs, consultez ma présentation CSSConf.eu 2017 « D'où vient le CSS ? » et les informations de fantasai dans ses articles "An Inside View of the CSS Working Group at W3C".