Miriam Suzanne est auteure, artiste et développeuse Web à Denver, dans le Colorado. Elle travaille actuellement sur des spécifications CSS intéressantes, comme les requêtes de conteneur et les calques en cascade.
Ce post fait partie de Designcember. Une célébration du design Web, proposée par web.dev.
Miriam Suzanne est auteure, artiste et développeuse Web à Denver, dans le Colorado. Elle est cofondatrice d'OddBird (une agence Web), rédactrice pour CSS Tricks, membre de l'équipe Sass et experte invitée du W3C au sein du groupe de travail CSS. Elle s'est récemment concentrée sur le développement de nouvelles fonctionnalités CSS telles que les calques en cascade, les requêtes de conteneur et la portée. Hors connexion, Miriam est romancière, dramaturge et musicienne. Nous avons parlé de son travail avec Sass et CSS.
Rachel : J'ai découvert votre travail grâce à votre framework de grille Susy. Qu'est-ce qui vous a poussé à le créer ?
Miriam : En 2008, la mise en page sur le Web était très différente. Les développeurs avaient abandonné la mise en page sous forme de tableau pour des grilles flottantes plus sémantiques (mais toujours un peu bricolées). Les "frameworks de grille" à 12 colonnes, qui offrent une grille prédéfinie (généralement statique) avec un ensemble de classes CSS prédéfinies, ont connu un essor. Si vous aviez besoin de quelque chose de plus personnalisable, vous deviez vous débrouiller seul. Il était clair que les sites Web devaient devenir plus réactifs, mais les requêtes média n'étaient pas encore disponibles et il existait de nombreux problèmes de compatibilité des navigateurs concernant les flottants fluides.
J'utilisais l'approche CSS Systems de Natalie Downe, qui était astucieuse pour répondre à la fois aux tailles de police et de fenêtre d'affichage, mais j'étais frustré par toutes les mathématiques répétitives et les hacks de navigateur requis. En même temps, Sass commençait à attirer l'attention et correspondait parfaitement à ce dont j'avais besoin. La première version de Susy était très simple : quelques mixins pour faire les calculs et ajouter les hacks dont j'avais besoin. L'objectif était de fournir un code minimal, en ne générant que l'essentiel. Grilles entièrement personnalisables, sans classes prédéfinies.
Rachel : Comment êtes-vous passée du développement d'un préprocesseur CSS à celui de spécifications CSS ? Pensez-vous que travailler sur le préprocesseur était une bonne base pour rédiger des spécifications ?
Miriam : D'après mon expérience, il y a beaucoup de points communs, et je suis toujours très active des deux côtés. Mais je pense que c'est en grande partie grâce à l'équipe Sass en particulier, dirigée par Natalie Weizenbaum, qui adopte une vision à très long terme et essaie de développer des outils qui s'intègrent facilement aux normes Web en développement. Il est essentiel de dépasser les solutions "opinionnées" universelles et de créer des solutions flexibles à long terme lorsque vous réfléchissez à l'avenir des normes Web de base.
Comment pouvons-nous créer des outils qui respectent la diversité des besoins et des approches des développeurs, tout en encourageant et en facilitant l'accessibilité et d'autres considérations importantes ?
Rachel : Nous avons beaucoup de choses qui arrivent dans CSS et qui remplacent essentiellement des fonctionnalités qui faisaient traditionnellement partie de Sass. Existe-t-il des raisons impérieuses d'utiliser encore un outil comme Sass ?
Miriam : Oui, pour certaines personnes, mais il n'y a pas de réponse universelle. Prenons l'exemple des variables. Les variables Sass sont de portée lexicale et compilées sur le serveur, avec des structures de données organisées telles que des listes et des objets, la manipulation des couleurs, etc. C'est idéal pour la logique du système de conception qui n'a pas besoin de s'exécuter dans le navigateur.
Les variables CSS se chevauchent parfois et peuvent également stocker des valeurs, mais elles présentent un ensemble de forces et de faiblesses entièrement différent en fonction de la cascade. Sass ne peut pas gérer les propriétés personnalisées, et CSS ne peut pas vraiment gérer les données structurées. Les deux sont utiles et puissants, mais vos besoins spécifiques peuvent varier.
Je pense que c'est une bonne chose de pouvoir éliminer les outils dont on n'a plus besoin. Certains projets peuvent ne pas nécessiter de variables côté serveur et côté client. Parfait. Mais il est trop simple de supposer que cela signifie qu'ils sont identiques et que l'un remplace simplement l'autre. Il y aura toujours des cas d'utilisation pour une logique de conception côté serveur et d'autres côté client, même si nous atteignons un point où les langages offrent essentiellement les mêmes fonctionnalités. Les préprocesseurs sont là pour durer.
Rachel : Y a-t-il quelque chose qui vous a surpris en vous impliquant davantage dans la création de normes, ou quelque chose que vous pensez que les gens en général ne savent pas sur le processus ?
Miriam : Avant de m'impliquer, le processus de normalisation me semblait être une boîte noire mystérieuse et magique, et je ne savais pas à quoi m'attendre. J'avais peur de ne pas avoir assez de connaissances sur le fonctionnement interne des navigateurs pour contribuer, mais la réalité est qu'ils n'ont pas besoin de plus d'ingénieurs en navigateurs. Ils ont besoin de plus de développeurs et de concepteurs qui créent des sites Web et des applications en production.
J'ai été surpris de constater que très peu de personnes impliquées se concentrent principalement sur les normes, mais aussi que très peu d'entre elles développent ou conçoivent principalement des sites Web. Le W3C est composé de "bénévoles" issus d'organisations membres (souvent rémunérés par ces organisations, mais pas à titre d'activité principale). L'adhésion n'est pas bon marché. Cela exclut les designers et développeurs qui travaillent au quotidien, en particulier ceux qui travaillent pour des clients dans de petites agences ou en freelance. Mon rôle d'expert invité serait totalement bénévole, un passe-temps coûteux, si je n'avais pas trouvé de financement externe pour ce travail.
En réalité, le processus est assez ouvert et public, et nécessite l'implication des développeurs. Cependant, il y a toujours tellement de conversations en même temps qu'il peut être difficile de trouver sa place. Surtout si ce n'est pas votre activité principale.
Rachel : Les requêtes de conteneur sont le Saint Graal de nombreux développeurs Web depuis des années. Je suis très heureux de les recevoir. J'ai l'impression que beaucoup de gens réfléchissent à l'utilité des requêtes de conteneur. Pensez-vous qu'elles peuvent aussi libérer davantage de créativité ?
Miriam : Absolument, même si je ne les considère pas comme entièrement distincts. Nous disposons tous d'un temps limité et nous essayons d'écrire du code performant et facile à gérer. Lorsque quelque chose est difficile à faire en pratique, nous sommes moins susceptibles de faire preuve de créativité pour trouver des solutions.
Toutefois, le secteur du Web est désormais dominé par de grands groupes, et ces préoccupations commerciales sont toujours plus mises en avant que celles des artistes Web. Je pense que nous perdons beaucoup si nous ignorons la créativité Web comme cas d'utilisation principal des fonctionnalités. J'ai été ravi de voir certains artistes CSS jouer avec le prototype de requête de conteneur. Jhey Tompkins a créé une démo particulièrement astucieuse et interactive de stores vénitiens en CSS en guise de commentaire sur l'ancien mème anti-CSS. Je pense qu'il y a encore beaucoup à explorer dans ce domaine, et j'ai hâte de voir ce que les gens vont encore inventer.
La conversation s'est également concentrée sur les requêtes basées sur la taille, comme cas d'utilisation initial, mais je suis impatient de voir ce que les gens feront avec les requêtes de style, c'est-à-dire la possibilité d'écrire des styles conditionnels en fonction de la valeur d'une propriété ou d'une variable CSS. Il s'agit d'une fonctionnalité extrêmement puissante, qui reste encore largement inexploitée. Je pense que cela ouvre encore plus de possibilités créatives !
Rachel : Y a-t-il des choses que nous ne pouvons pas faire (ou que nous pourrons bientôt faire) en CSS et qui, selon toi, seraient utiles ?
Miriam : Je suis très enthousiaste à propos d'autres spécifications sur lesquelles j'ai travaillé. Les calques en cascade donneront aux auteurs plus de contrôle sur les problèmes de spécificité, et Scope devrait aider à cibler les sélecteurs de manière plus précise. Mais ces deux aspects concernent l'architecture de haut niveau. L'artiste qui sommeille en moi est plus enthousiaste à l'idée de bascules CSS, d'une manière déclarative de créer des styles interactifs ou de "chronologies" de conteneurs, qui nous permettent de faire passer en douceur les valeurs entre les points d'arrêt média ou de conteneur. Cela a des implications très pratiques pour la typographie responsives, mais cela ouvrirait également de nombreuses opportunités créatives pour l'art et l'animation responsives.
Rachel : Qui d'autre fait des choses vraiment intéressantes, amusantes ou créatives sur le Web en ce moment ?
Miriam : Oh, je ne sais même pas comment répondre à cette question, il y a tellement de personnes qui font des travaux créatifs dans des domaines si différents. Le CSSWG et Open-UI travaillent actuellement sur de nombreuses normes intéressantes, y compris sur la fragmentation. Mais je trouve souvent l'inspiration auprès des artistes Web et de la façon dont les gens utilisent ces outils en production, d'une manière qui n'est pas directement liée au commerce. Des personnes comme Jhey, Lynn Fisher, Yuan Chuan et bien d'autres repoussent les limites de ce que les technologies Web peuvent faire en termes de visuels et d'interactivité. Même les personnes qui travaillent davantage sur des tâches axées sur l'activité peuvent apprendre beaucoup de leurs techniques artistiques.
J'apprécie également l'art Web plus conceptuel de personnes comme Ben Grosser, qui nous pousse sans cesse à reconsidérer ce que nous attendons du Web, et des réseaux sociaux en particulier. Par exemple, découvrez son nouveau minus.social.
Rachel : Suivez le travail de Miriam sur les CSS sur css.oddbird.net et découvrez ce qu'elle fait d'autre sur son site Web miriam.codes et sur Twitter @TerribleMia.