Miriam Suzanne est auteur, artiste et développeur Web à Denver, dans le Colorado. Il travaille actuellement sur des spécifications CSS intéressantes, telles que les requêtes de conteneur et les couches Cascade.
Cet article a été publié dans Designcember. Un hommage à la conception Web comme web.dev pour vous.
Miriam Suzanne est auteur, artiste et développeur Web à Denver, dans le Colorado. Elle est cofondatrice d'OddBird (une agence Web), rédactrice en chef de l'équipe CSS Tricks, membre de l'équipe principale Sass et experte invitée du W3C au groupe de travail CSS. Elle s'est récemment concentrée sur le développement de nouvelles fonctionnalités CSS telles que les couches Cascade, les requêtes de conteneurs et le champ d'application. Hors connexion, Miriam est un romancier, dramaturge et musicien publié. 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 amené à le créer ?
Miriam:En 2008, la mise en page sur le Web représentait une expérience très différente. Les développeurs sont passés de la mise en page des tables aux grilles flottantes plus sémantiques (mais toujours hackanes). 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 étiez 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 y avait de nombreux problèmes de compatibilité des navigateurs avec les floats fluides.
J'utilisais l'approche CSS Systems de Natalie Downe, qui était intelligente pour répondre aux tailles de police et de fenêtre d'affichage, mais j'étais frustrée par toutes les opérations répétitives de calcul et de piratage des navigateurs nécessaires. Au même moment, Sass commençait à attirer l'attention, et elle répondait parfaitement à mes besoins. La première version de Susy était très simple: je n'ai fait que quelques mixages pour faire le calcul et ajouter les astuces dont j'avais besoin. L'objectif était d'être minimal et de ne générer que le code essentiel. Grilles totalement personnalisables, sans classes prédéfinies.
Rachel:Comment êtes-vous passé d'un préprocesseur CSS au travail sur les spécifications CSS ? Pensez-vous que le travail sur le préprocesseur était une bonne expérience pour la rédaction des spécifications ?
Miriam:D'après mon expérience, il y a de nombreux points communs et je reste très actif sur les deux côtés de cette fracture. Mais je pense que c'est en grande partie grâce à l'équipe Sass, dirigée par Natalie Weizenbaum, qui a une vision à très long terme, en essayant de développer des outils qui s'intègrent parfaitement au développement de normes Web. Lorsque vous envisagez l'avenir des principales normes Web, il est essentiel d'aller au-delà des solutions génériques " tout public" et de développer une flexibilité à long terme.
Comment créer des outils qui respectent la diversité des besoins et approches des développeurs, tout en encourageant et en facilitant l'accessibilité, ainsi que d'autres considérations importantes ?
Rachel:De nombreux éléments arrivent dans CSS et remplacent les fonctionnalités traditionnellement intégrées à Sass. Y a-t-il de bonnes raisons d'utiliser toujours quelque chose 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 ont une portée lexique et sont 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 parfait pour la logique de système de conception qui n'a pas besoin de s'exécuter dans le navigateur.
Les variables CSS présentent un certain chevauchement. Elles peuvent également stocker des valeurs, mais elles offrent un ensemble complètement différent de points forts et de points faibles basés sur des cascades. 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 toutes deux efficaces, mais vos besoins spécifiques peuvent varier.
Je pense que c'est génial lorsque les gens peuvent éliminer des outils dont ils n'ont plus besoin et que certains projets ne nécessitent pas de variables à la fois côté serveur et côté client. Parfait. Mais il est trop simple de supposer qu'ils sont identiques, et que l'un remplace simplement l'autre. Il y aura toujours des cas d'utilisation pour que certaines logiques de conception se produisent côté serveur et d'autres côté client, même si nous arrivons à ce que les langages fournissent essentiellement les mêmes fonctionnalités. Les préprocesseurs sont à nos côtés sur le long terme.
Rachel:Y a-t-il quelque chose qui vous a surpris lorsque vous vous êtes davantage impliqué dans le travail de création de normes, ou quelque chose que les gens ne connaissent généralement pas au sujet du processus ?
Miriam:Avant de m'impliquer, le processus de normalisation ressemblait à une boîte noire mystérieuse et magique, et je ne savais pas à quoi m'attendre. J'avais peur de ne pas avoir suffisamment de connaissances sur les composants internes du navigateur pour apporter ma contribution, mais en réalité, ils n'ont pas besoin de plus d'ingénieurs de navigateur. Ils ont besoin de plus de développeurs et de concepteurs qui créent des sites Web et des applications dans la nature.
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 constitué de « bénévoles » d'organisations membres (souvent rémunérés par ces organisations, mais pas en tant que travail principal), et les adhésions sont payantes. Cela éloigne les participants des concepteurs et des développeurs quotidiens, en particulier ceux d'entre nous qui travaillent pour des clients dans de petites agences ou des indépendants. Mon rôle d'expert invité serait entièrement bénévole, un passe-temps coûteux, si je n'avais pas trouvé de financement extérieur pour ce travail.
En réalité, le processus est relativement ouvert et public, et nécessite la participation des développeurs. Cependant, il y a toujours tellement de conversations qui ont lieu en même temps, qu'il peut être difficile de trouver votre place. Surtout si ce n'est pas votre travail.
Rachel:Les requêtes de conteneur sont le Saint Graal de nombreux développeurs Web depuis de nombreuses années. Je suis très enthousiaste à l'idée que nous les ayons reçues. J'ai l'impression que beaucoup de gens réfléchissent à l'utilité des requêtes de conteneur. Pensez-vous qu'elles peuvent également stimuler la créativité ?
Miriam:Absolument, même si je ne pense pas qu'ils soient totalement séparés. Nous avons tous un temps limité et nous essayons d'écrire du code facile à gérer et performant. Lorsque les choses sont difficiles à réaliser, nous sommes moins susceptibles d'être créatifs.
Pourtant, l'industrie du Web est aujourd'hui dominée par les grandes entreprises. Ces préoccupations ont donc toujours plus de temps d'être que les artistes du Web. Et je pense que nous perdons beaucoup si nous ignorons la créativité sur le Web comme principal cas d'utilisation des fonctionnalités. J'ai vraiment hâte de voir des spécialistes de l'art CSS jouer avec le prototype de requête de conteneur. Jhey Tompkins a créé une démonstration particulièrement intelligente et interactive des stores vénitiens CSS pour commenter l'ancien mème anti-CSS. Je pense qu'il y a encore beaucoup à découvrir dans ce domaine, et j'ai hâte de voir ce que d'autres personnes vont nous proposer.
La conversation s'est également concentrée sur les requêtes basées sur la taille, comme le cas d'utilisation initial. Mais j'ai hâte de voir ce que les utilisateurs font avec les requêtes de style : la possibilité d'écrire des styles conditionnels en fonction de la valeur d'une propriété ou d'une variable CSS. Cette fonctionnalité extrêmement performante n'a pas encore été explorée. Je pense que cela ouvre encore plus d'opportunités de création !
Rachel:Selon vous, y a-t-il quelque chose que nous ne pouvons pas faire (ou que nous avons bientôt) dans CSS ?
Miriam:J'ai hâte de découvrir d'autres spécifications sur lesquelles j'ai travaillé. Les calques de cascade permettront aux auteurs de mieux contrôler les problèmes de spécificité, tandis que le champ d'application devrait les aider à cibler plus précisément les sélecteurs. Mais il s'agit de problèmes d'architecture de haut niveau. L'artiste que j'aime est plus enthousiaste à l'égard des boutons d'activation/de désactivation CSS, de la façon déclarative de créer des styles interactifs ou des "chronologies" des conteneurs, qui nous permettent d'effectuer des transitions fluides entre les valeurs des médias ou des conteneurs. Cela a des implications très pratiques pour la typographie responsive, mais ouvre également de nombreuses possibilités de création pour le graphisme et l'animation responsifs.
Rachel:Qui d'autre fait un travail vraiment intéressant, amusant ou créatif sur le Web en ce moment ?
Miriam:Je ne sais même pas comment répondre à cette question, car il y a tellement de personnes qui réalisent des créations dans des domaines aussi différents. De nombreuses normes intéressantes sont en cours pour le CSSWG et l'OpenUI, y compris une partie de votre travail sur la fragmentation. Mais ce sont souvent les artistes du Web qui m'inspirent le plus et la façon dont ils mettent ces outils en production, sans lien direct avec le commerce. Des personnes comme Jhey, Lynn Fisher ou Yuan Chuan, ou bien d'autres encore, qui repoussent les limites des technologies Web, visuellement et interactives. Même les personnes qui travaillent davantage pour une entreprise peuvent apprendre beaucoup de leurs techniques artistiques.
J'apprécie également l'art Web plus conceptuel de personnes comme Ben Grosser, qui ne cesse de nous pousser à reconsidérer ce que nous attendons du Web, et en particulier des réseaux sociaux. Découvrez son nouveau minus.social, par exemple.
Rachel:Pour en savoir plus sur le travail de Miriam concernant les CSS sur css.oddbird.net, consultez son site Web sur miriam.codes et Twitter (@TerribleMia).