Carnet de notes

Catégorie : CSS

  • Nouveau tour dans les CSS-in-JS

    L’his­toire

    J’ai aban­donné mes premiers amours qu’é­taient les feuilles de style sépa­rées avec des nommages bien séman­tiques. Je travaille par les appli­ca­tions front-end par compo­sants, j’ai besoin que les styles fonc­tionnent de façon simi­laire.

    BEM était une bonne idée mais impra­ti­cable. Le nommage est pénible et il fallait encore garder une synchro­ni­sa­tion entre la feuille de style et les compo­sants. J’ai eu plai­sir à trou­ver CSS Modules mais on conti­nue à jongler sur deux fichiers distincts avec des imports de l’un à l’autre. Il fallait faire mieux.

    J’ai besoin que les styles soient édités au même endroit que les compo­sants, toujours synchro­ni­sés, mis à jour en même temps, limi­tés chacun au compo­sant ciblé.

    Tail­wind a trouvé une solu­tion à tout ça en géné­rant statique­ment la feuille de style à partir des compo­sants eux-mêmes. Je comprends pourquoi ça plaît mais je n’ar­rive pas à consi­dé­rer que redé­fi­nir tout un pseudo-langage paral­lèle puisse être une bonne idée. On finit toujours par devoir apprendre CSS, que ce soit pour expri­mer quelque chose que le pseudo-langage ne permet pas, ou simple­ment pour comprendre pourquoi le rendu n’est pas celui qu’on imagine.

    Je suis parti vers les solu­tions CSS-in-JS quand je code du React. Faire télé­char­ger et exécu­ter toute une biblio­thèque comme Emotion est loin d’être idéal mais ça reste fina­le­ment assez négli­geable sur une appli­ca­tion front-end moderne.

    Entre temps j’ai quand même décou­vert Goober, qui implé­mente le prin­ci­pal en tout juste 1 ko. L’éli­mi­na­tion des styles morts contre­ba­lance proba­ble­ment large­ment ce 1 ko de Javas­cript. On aurait pu en rester là.

    La mise à jour

    Je suis quand même gêné de devoir embarquer une biblio­thèque Javas­cript. J’ai fouillé voir si rien de mieux que Goober et Emotion n’avait pointé le bout de son nez depuis la dernière fois que j’ai tout remis en cause. Il se trouve que le paysage a sacré­ment évolué en cinq ans.

    D’autres que moi ont eu envie d’al­ler vers du plus simple. On parle de zero-runtime. Les styles de chaque compo­sant sont extraits à la compi­la­tion pour créer une feuille de style dédiée. Les parties dyna­miques sont faites soit avec des variantes prédé­fi­nies, soit avec des variables CSS qui sont ensuite mani­pu­lée par Javas­cript via les attri­buts `style`.

    Le véné­rable c’est Vanilla-extract mais on a juste une version plus complexe et entiè­re­ment Javas­cript des CSS-Modules. C’est d’ailleurs le même auteur, et le même problème fonda­men­tal : deux fichiers distincts à mani­pu­ler et à synchro­ni­ser.

    Vient ensuite Lina­ria qui semble une vraie merveille. Il a l’es­sen­tiel de ce que proposent les CSS-in-JS avec de l’ex­trac­tion statique avec tout ce qu’on attend au niveau de l’ou­tillage : types­cript, source maps, prépro­ces­seur et véri­fi­ca­tion de syntaxe, ainsi que l’in­té­gra­tion avec tous les cadres de travail clas­siques.

    Lina­ria c’est aussi WyW-in-JS, qui opère toute la partie extrac­tion et trans­for­ma­tion, au point de permettre à qui veut de créer son propre outil concur­rent à Lina­ria. Je trouve même cette réali­sa­tion bien plus signi­fi­ca­tive que Lina­ria lui-même.

    L’équipe de MUI en a d’ailleurs profité pour faire Pigment-CSS et conver­tir tout MUI. Pigment reprend tout le prin­cipe de Lina­ria avec la gestion des thèmes, la gestion des variantes, et quelques raccour­cis syntaxiques pour ceux qui aiment l’ap­proche de Tail­wind. En échange, ces fonc­tion­na­li­tés ne sont possibles qu’en écri­vant les CSS sous forme d’objets Javas­cript plutôt que sous forme de texte CSS direc­te­ment. La biblio­thèque est aussi plus jeune et la compa­ti­bi­lité avec tous les cadres de travail ne semble pas assu­rée.

    J’ai aussi traversé Panda-CSS mais sans être convaincu. Panda génère tout en statique mais il génère tout une série d’uti­li­taires et de variables par défaut, et injecte beau­coup d’uti­li­taires dans le Javas­cript qui sera exécuté avec l’ap­pli­ca­tion. C’est un croi­se­ment entre Emotion, Tail­wind et Lina­ria, mais qui du coup me semble un peu Fran­ken­stein. À vouloir tout à la fois, on finit par ne rien avoir de franc.

    Si c’est pour utili­ser avec MUI, le choix se fait tout seul. Dans le cas contraire, au moins pour quelques mois le temps que Pigment-CSS se déve­loppe un peu plus, Lina­ria me semble un choix plus sage. S’il y a quoi que ce soit qui coince, Goober reste une solu­tion prag­ma­tique et tout à fait accep­table.

  • Today I lear­ned : font-variant-nume­ric

    Conseil CSS : utili­sez `font-variant-nume­ric: tabu­lar-nums;` pour aligner soigneu­se­ment les nombres dans un tableau, des comp­teurs de progres­sion, etc.

    https://twit­ter.com/javan/status/1486059026064584711

  • Où je dis du bien du CSS-in-JS

    Il n’y a que les imbé­ciles qui ne changent pas d’avis et c’est mon avis depuis toujours

    Coluche

    J’ai toujours regardé avec dédain les tenta­tives des dev JS pour contour­ner l’écri­ture de CSS mais je commence à consi­dé­rer que les outils de CSS-in-JS type Emotion sont la bonne solu­tion pour les webapp React.

    J’ai été inté­gra­teur, à faire de la belle CSS sépa­rée du code HTML. On finit quand même vite par construire des monstres ou se prendre les pieds dans le tapis dès qu’on fait plus de quelques pages types.

    Pour résoudre le problème, élimi­nons le. C’est ce que proposent les conven­tions comme BEM. Si je cari­ca­ture, il s’agit prin­ci­pa­le­ment de reti­rer les sélec­teurs CSS un attri­buant une ou plusieurs classes spéci­fiques à chaque contexte. C’est fran­che­ment moche mais ça fonc­tionne.

    CSS-Modules va un peu plus loin. Le prin­cipe est le même mais on permet au déve­lop­peur d’uti­li­ser un nommage plus agréable. C’est l’ou­til de géné­ra­tion qui gère la complexité au lieu du déve­lop­peur.

    J’avoue que j’aime bien CSS-modules. C’était mon favori jusqu’à présent.

    Ça revient à juste gérer un fichier par compo­sant en se limi­tant à des sélec­teurs très simples pour ne pas créer de conflits de spéci­fi­cité. On reste sur du CSS stan­dard et sur une approche proche de mes habi­tudes histo­riques. Mieux : L’in­té­gra­tion peut se faire indé­pen­dam­ment du langage de déve­lop­pe­ment de l’ap­pli­ca­tif.

    C’est top mais ça se base sur des compo­sants qui ne bougent pas beau­coup, dont on connait à l’avance tous les états.

    Dès qu’il s’agit de cumu­ler plusieurs états, le résul­tat dépend de l’ordre d’écri­ture dans la CSS. Parfois c’est bien prévu, parfois non.

    Dès qu’il s’agit de rendre des choses très dyna­miques, il faut de toutes façons sortir des CSS modules. Vous voulez que dans la vue large les items de navi­ga­tion se colorent au survol en fonc­tion de la caté­go­rie desti­na­tion déter­mi­née dyna­mique­ment mais qu’ils utilisent la couleur neutre dans la vue réduite desti­née aux mobiles ? Vous êtes à poil et il va falloir compo­ser avec d’autres façons d’injec­ter des CSS, peut-être même tâton­ner sur les prio­ri­tés entre classes.

    Les classes utili­taires et CSS atomiques à la Tachyon sont là pour indus­tria­li­ser en pous­sant encore plus loin.

    J’ai une classe par valeur à appliquer : .ms7-ns applique la septième valeur du cata­logue (7) comme taille hori­zon­tale maxi­mum (ms pour max-width) si la fenêtre a une taille supé­rieure au point de rupture « small » (ns pour non-small).

    Ça n’offre quasi­ment aucune abstrac­tion utile (unifor­mi­ser les valeurs on a déjà plein d’ou­tils plus effi­caces). C’est vite cryp­tique, lourd, et mons­trueux dès qu’on multi­plie les valeurs et les points de rupture possibles.

    Le seul inté­rêt par rapport à écrire direc­te­ment les attri­buts style c’est que ça permet d’ac­cé­der aux media query et aux pseudo-sélec­teurs.

    Malheu­reu­se­ment non seule­ment ça ne résout pas les conflits de prio­ri­tés mais ça les empire. Si je spécia­lise un compo­sant exis­tant en y ajou­tant une classe liée à une direc­tive déjà présente, je joue à la roulette russe. Il faut abso­lu­ment que mon compo­sant initial prévoit lui-même tous les cas possibles pour savoir quelle classe injec­ter et ou ne pas injec­ter. Pas d’al­ter­na­tive.

    J’ai vrai­ment l’im­pres­sion d’un retour en arrière mons­trueux avec ces CSS atomiques, cumu­ler les défauts sans aucun avan­tage, et c’est proba­ble­ment ce qui m’a fait reje­ter par prin­cipe les CSS-in-JS jusqu’a­lors.

    Les CSS-in-JS c’est fina­le­ment pous­ser la logique de Tachyons un cran plus loin. Quitte à déci­der de tout dans le code HTML, autant écrire direc­te­ment les styles à cet endroit là en utili­sant la vraie syntaxe CSS et en y ajou­tant la possi­bi­lité d’ac­cé­der aux media query et aux pseudo-sélec­teurs.

    Emotion c’est ça. On est à la croi­sée entre le « j’écris tout dans un attri­but style » et le « j’at­tache un module CSS ».

    En fonc­tion­ne­ment basique c’est comme un CSS module sans le sélec­teur. Je donne les direc­tives en CSS on ne peut plus clas­siques et j’ai accès aux media query, aux pseudo-sélec­teurs et aux anima­tions avec une syntaxe proche de ce que font les prépro­ces­seurs habi­tuels (et en phase avec la direc­tion que prend la syntaxe CSS elle-même).

    const style = css`
      padding: 32px;
      background-color: hotpink;
      font-size: 24px;
      border-radius: 4px;
      &:hover {
        color: blue;
      }
    `

    Je peux direc­te­ment ajou­ter le résul­tat aux classes CSS de mon compo­sant. Il se char­gera de géné­rer un nom de classe, de créer la CSS corres­pon­dante dans le docu­ment, et de lier les deux, comme avec CSS-Modules.

    L’exemple est peu parlant. On a juste l’im­pres­sion d’un CSS-Modules écrit dans le fichier JS.

    L’avan­tage c’est que je ne suis pas limité aux valeurs en dur. Je peux avoir des valeurs dyna­miques venant de mon Javas­cript ou de mon thème, et je n’en limite pas les effets à ce que me permettent les variables CSS.

    Je peux aussi réuti­li­ser, compo­ser ou surchar­ger un élément ou un bloc de styles avec un autre sans risque de conflit de prio­rité.

    Tachyons me donnait l’im­pres­sion de cumu­ler les incon­vé­nients, ici j’ai vrai­ment l’im­pres­sion de cumu­ler les avan­tages.

    La seule contrainte c’est que mon code CSS se retrouve dans mes fichiers JS. C’est moche quand c’est dit ainsi mais pour une app en React, on a de toutes façons un fichier par compo­sant HTML et ça a du sens de grou­per HTML, JS et CSS lié au compo­sant ensemble quand ils sont forte­ment liés. C’est d’ailleurs le choix de VueJS.

    Ce n’est forcé­ment pas adapté à tout, et si vous voulez rester géné­riques les CSS-Modules sont à mon avis l’op­tion la plus saine, mais pour un code React je crois que c’est là que je commen­ce­rai par défaut désor­mais.

  • Rempla­cer du texte par une image en CSS

    Dans les années 2007 à 2009 on avait une collec­tion d’hor­ribles bidouilles CSS pour insé­rer des images à la place de certains textes via CSS. L’idée c’est que certaines images ne sont pas du contenu mais bien de la présen­ta­tion, poten­tiel­le­ment dépen­dantes du contexte.

    Le besoin était tel que c’était un des sujets les plus en vue en CSS pendant des années avec « comment centrer un contenu verti­ca­le­ment ».

    h3.nir {
   height: 75px;
   width: 300px;
   overflow: hidden;
   margin: 0;
   padding: 0;
 }
 h3.nir:before {
   content: url(http://…/test.png);
   display: inline-block;
   font-size: 0;
   line-height: 0;
 }

    Fran­che­ment c’était de la bidouille de haut vol, avec plein de défauts. On rêvait d’un truc plus simple, qui fonc­tionne correc­te­ment quand l’image ne se charge pas et sur les lecteurs d’écran, sans flash de contenu non stylé. Je me demande même ce qui suit n’a fonc­tionné sur certains navi­ga­teurs, mais on n’y est visi­ble­ment pas encore :

    h3 { content: url(http://…/test.png); }

    CSS a beau­coup évolué, les navi­ga­teurs aussi. J’es­pé­rais qu’on avait enfin résolu ce problème ultra bateau. Visi­ble­ment non. La seule solu­tion passe par des polices de carac­tères d’icônes et des recon­nais­sances de liga­ture. Le reste n’a que peu changé en 10 ans, on a juste enlevé les besoins de compa­ti­bi­lité sur les vieux navi­ga­teurs.

    J’avoue que je ne comprends pas. On ajoute des fonc­tion­na­li­tés de folie et on ne gère toujours pas la base qui a généré des milliers de pages en bidouilles de contour­ne­ment. Qu’on m’ex­plique…