CSS - Le topic des mecs qui ont la .class

Dev
12

En fait @mhash tu t’es répondu à toi même sur l’intérêt de Tailwind. Tu fais en gros du CSS avec des composants agnostiques que tu customises avec des classes utilitaires.

Tailwind est simplement l’extension de ce système sauf qu’il est inversé. Habituellement nous les intés on fait une abstraction avant de coder de ce qui doit être un composant. Tailwind propose de créer cette abstraction après les faits, quand on voit que le pattern se répète et qu’il mérite donc de devenir une abstraction.

C’est à cela que sert la fonction @apply (lien), et aussi parce que eux aussi trouvent cela illisible tous ces noms de classe. L’exemple donné dans l’article est assez clair : combien de fois tu réutilises une navbar? Aucune fois ou presque, tu en fais une et basta. Du coup est-ce vraiment utile d’en faire une abstraction ? Probablement pas, des classes utilitaires suffisent.

En soi c’est pour ce workflow que je trouve Tailwind intéressant et que je vais l’essayer. Je pense que ça peut rendre le boulot moins pénible et plus efficace. J’étais pas du tout convaincu pour les même raisons que beaucoup, notamment parce qu’il faut se mettre d’accord si qui crée les classes utilitaires et est-ce qu’elles sont assez complètes pour permettre la souplesse dont on a besoin ? Et aussi comment faire pour que personne ne crée une duplicate de classe utilitaire ou une nouvelle règle de style ? Mais si on utilise Tailwind qui apporte la majorité des classes nécessaires, on évitera ce problème aussi.

Bref je sens que c’est pas naturel ce qu’ils proposent, mais j’ai envie d’essayer. Je le prendrais pas pour tous les projets (notamment pour les petits) mais pour les gros cela pourrait carrément aider.

13

C’est horrible. C’est encore un unième framework de css fait par des devs qui ne veulent rien comprendre aux css.

 class="text-cyan-600"

Avec ce genre de code si tu dois changer de couleur tu dois repasser dans tout ton html pour la changer C’est assez proche de la tendance des composants css in js avec l’émergence de React. Par méconnaissance le dev ne veut aucun effet des bords des css, donc il va tout redéfinir dans chaque composants :poop:

3 « J'aime »
14

Je n’accroche pas plus à ce système que celui du precepte de nommage des class
.className {.className__titre {}}

Dans le premier cas on se retrouve avec une myriade de cas particuliers pour traiter à chaque fois un style comme par exemple ici :
→ " absolute max-w-none object-cover bg-gray-100 "
Ce qui revient pour moi à faire du [style = " "] à l’ancienne ou pas loin.
Autant écrire les choses proprement en CSS dès le départ non ?

Et tu soulève un point important, comment sont définies ces class, à partir de quoi ?
Concernant les class redontantes, je doute que ce système en vienne à bout.
Tu prends l’exemple de la navbar, mais justement, on a une classe qu’on utilise une seule fois, certes, mais elle est supposément censé impacter les éléments enfants pour lesquels on ne va pas voir besoin d’ajouter des class en boucle sauf cas particulier.
Il est clairement identifiable et identifié.

Et dans le second cas, on se retrouve à nommer les class de façon excessivement lourde et pénible (et qui n’apporte pas grand chose à sa compréhenion voir pire). Personnellement je n’applique pas ce " precepte ". Precepte d’autant plus inutile avec les class impbriquées qui permettent d’avoir une lecture rapide et simple.

@cedric
Totalement d’accord :sweat_smile:

15

Ce manque d’humilité me consterne :pensive:

1 « J'aime »
16

Bin y a toujours 2 façons de faire:

  • tordre l’outil pour l’adapter a ses pratiques
  • tordre ses pratiques pour s’adapter à l’outil

Vu la divesrité des usecases en info, pas sur que l’un soit mieux que l’autre :slight_smile: .

1 « J'aime »
17

Vous êtes sacrément dogmatiques quand même.

Sauf que… non ? Tailwind utilise, comme presque tout le monde maintenant, des custom properties. Donc si la valeur de ton cyan doit changer, tu changes la variable et tu recompiles. Si tu passes d’un cyan à un bleu, dans ce cas évidemment tu vas devoir repasser sur ton html pour garder une cohérence entre nom de classe et contenu, et dans ce cas c’est pareil avec ou sans tailwind.

Quand au « tout redéfinir dans chaque composant » évidemment que non. Même un dev un peu naze en CSS saura que s’il fait un bouton il va faire un style neutre, puis après faire d’autres composants qui importent ce bouton pour, par exemple, lui ajouter une couleur. En cela on est pas très loin de l’object oriented css qu’on connait bien.

Sauf que non rien à voir avec du style inline. Un style inline tu peux lui faire dire ce que tu veux et tu va vite perdre en cohérence. En inline tu ne peux pas en changer par exemple une taille dans une classe et voir la répercussion sur l’ensemble de ton projet. Je veux bien qu’on trouve moche ce que fait Tailwind (c’est mon cas) mais de là à comparer à du style faut vraiment faire preuve de mauvaise foi. Cela reste des classes.

Tailwind tout comme Bootstrap te permet de définir tes tailles, couleurs, etc. Du coup une fois que tu as fait ta config les classes comme text-small prennent les valeurs que tu as donné.

Absolument pas d’accord avec ça, en particulier sur des codebases avec de nombreux devs. BEM fonctionne très bien même pour quelqu’un qui connaît pas une codebase ou même le CSS : __ c’est un enfant, – c’est une version alternative. Il faut savoir l’utiliser (pas de double __ ou – par exemple) pour en faire quelque chose de bien mais c’est comme tous les outils.

Ton principe d’agencer des classes dans des classes (notamment en SASS/LESS où tu peux nest les classes) crée du code beaucoup plus dur à maintenir et à faire évoluer. C’est d’ailleurs aussi une mauvaise pratique en ce qui concerne la spécificité et la performance. Le CSS étant lu par le navigateur de droite à gauche, enchaîner les classes déclenche plus de repaint que d’avoir des classes en BEM qui ne sont pas imbriquées les unes dans les autres.

(Merci @Cafeine pour le split !)

5 « J'aime »
18

Certes cela reste des classes mais c’est à peine mieux que du style inline dans le sens où comme je le disais plus haut, on multiplie les surcharges pour se retrouver quasiement avec une classe = un style.

Concernant le BEM, c’est un plan de nommage que personnellement je n’apprécie pas car il allourdie terriblement le scss / sass et sa lecture et que je n’utilise pas autant que possible.

A mon sens les classes imbriquées remplissent parfaitement ce rôle justement grâce à cette notion de hiérarchie qui est plus rapide à écrire, moins pesant et plus lisible.

Je parle de SCSS / SASS etc. sachant qu’à la sortie on aura bien du CSS strict avec le transpileur et donc pas de classes imbriquées.

19

Et sinon, histoire de pas être d’accord sur un autre sujet :stuck_out_tongue: , il y en a parmi vous qui utilisent Slim ?

http://slim-lang.com
(c’est écrit Ruby, mais il existe des moteurs Slim pour plein de langages)

J’ai utilisé HAML pendant des années, mais je préfère encore slim :slight_smile:

20

Moi ce que je vois en découvrant ce thread à l’instant c’est qu’on pourra invoquer tous les termes qu’on veut, y’aura tjs cet éternel débat entre les devs qui pensent savoir faire du CSS et ceux qui savent véritablement s’en servir (c’est-à-dire ceux qui savent aligner un contenu verticalement en 2020 - je caricature à peine, même combat « c’est quoi la différence entre un div et un span ? »).

C’est encore un unième framework de css fait par des devs qui ne veulent rien comprendre aux css.

les classes c’est pareil que le inline

bitches please -_-

Oui, Tailwind, ça semble très bien, et y’a qu’à voir les dernières itérations de Bootstrap, c’est environ pareil (en moins fourni ofc, Tailwind est so much richer), sauf que Bootstrap est plus user friendly parce qu’il propose directement ses composants tout fait.

Là l’idée c’est juste de permettre de s’affranchir justement des composants tout fait et de les construire en live sans avoir à embarquer un framework « plus gros et plus connu » ou trouver les composants qui fit à tes besoins.
Alors oui, c’est pas pour tout le monde, et pour quelqu’un à qui le CSS et le HTML ça ne parle pas, utiliser Tailwind ça va vite être l’enfer, mais si t’es rigoureux et que t’as rien d’autre, bah c’est pas forcément un mauvais choix.

Regardez les design system (DS) qui fleurissent ces derniers mois/années, vous verrez que environ tout le monde se redirige vers ce genre de trucs. Tailwind s’affranchit juste en plus de proposer des composants et de fournir quelque chose de bien plus complet et extensible / souple que ce qui existe (et encore vu que le truc est en bêta j’suis sûr que sur son modèle, il va en sortir).

Moi-même qui suis en train de construire un DS from scratch dans ma boîte (ça va faire 5 ans que je me dis qu’il faut, 5 ans qu’on utilise Bootstrap 3, et quasi 5 mois que je bosse dessus en solo), j’ai commencé à l’écrire en me disant « bon, on va pas péter les habitudes des devs avec nos déjà 30+ apps qui sont en Bootstrap, donc je vais le baser sur une version plus moderne de Bootstrap », et franchement rien qu’avec la version 4 de Bootstrap, je me dis que finalement filer Tailwind aux devs avec des bonnes guidelines maison, des exemples pertinents et une doc aux ptits oignons pourrait largement suffire.

(bon en vrai je vais continuer sur Bootstrap 4 parce que la flemme et d’autres choses)

2 « J'aime »
21

Non elles ne remplissent pas ce rôle du tout. Si on part du principe que ton SASS compile tout à plat (donc pas de .btn.rouge par exemple) ça devrait ressembler à ça (j’ai pas fait de SASS depuis un bail) :

.btn {
    //style principal

    &-rouge {
        //
    }

    &-jaune {
        //
    }

    &-small {
        //
    }

    &-medium {
        //
    }

    &-large {
        //
    }

    &-svg {
        //
    }

    &-spinner {
        //
    }

Cette hiérarchie des classes fait que tu ne sais pas si une classe imbriquée est un enfant de la classe parente ou une version alternative, et c’est pour ça que BEM (et d’autres systèmes de nommage soyons pas sectaires) existent. Ce système rend aussi la debug super compliqué sur une codebase que tu connais pas si jamais il y a pas de sourcemap. Tu cherches la classe btn-rouge et impossible de la trouver ? Faut chercher btn, puis scroller pour trouver la seconde partie.

Quand on est dev solo sur un petit ou moyen projet ok, ça peut se faire. Mais dès qu’on est plus de deux et que le projet est large, je n’ai jamais vu ce système fonctionner. A noter d’ailleurs que même en ajouter BEM, l’imbrication du code rend fou.

Ca resemble vachement à PUG. Perso je suis pas contre mais dès que ton HTML devient compliqué je pense qu’il est aussi complexe à lire avec que sans un système de templating. :smiley:

This. Prétendre que du style inline c’est pareil que des classes utilitaires c’est franchement faire preuve de mauvaise foi. Je veux bien que le paradigme de Tailwind plaise pas mais faudrait pas sortir des énormités pareilles.

2 « J'aime »
22

connais pas PUG
Le principe de slim est que ca utilise l’indentation pour fermer automatiquement les balises à ta place. Du coup il y a plusieurs bénéfices :

  • plus besoin de se farcir des balises à fermer
  • le code est plus léger à lire (car si on retire toutes les balises fermantes ca fait bcp de code en moins)
  • mais surtout, l’indentation du fichier est TOUJOURS propre (car si le fichier est mal indenté, ca fonctionne pas)
23

Ici ils répondent : Why not just use inline styles? (au passage la doc de tailwind est vraiment top :heart_eyes:)

1 « J'aime »
24

Mais justement, je trouve cette syntaxe horrible à lire et difficile à comprendre car dans le HTML, ces classes seront indiquées comme ceci : btn-rouge / btn-jaune etc.

Dans l’absolu ça ne semble pas si compliqué que ça mais si les noms deviennent un peu long, c’est l’enfer.
J’ai personnellement un vrai problème avec ce morcellement des noms, j’ai horreur de ça ^^’

Quand je parle de hiérarchisation, je parle de ce genre de cas de figure :

.mon-bloc {
        //
    .mon-bloc-titre {
        //
    }
    .mon-bloc-texte {
        //
    }
}
25

Les utilisateurs de python te diront que c’est pas vrai :sweat_smile:. Même avec un système comme ça, tu peux avoir du code crade et illisible.

3 « J'aime »
26

Perso j’utilise auto-close-tags sur Vscode pour auto-fermer parce que comme toi j’ai la flemme de ouf. :laughing: Pour le reste je suis pas géné par le html niveau lecture, mais probablement parce que j’utiliser un linter/prettier et que je découpe beaucoup en sous-fichiers/composants. Dans les gros templates par contre je vois carrément le bénéfice.

Ouais mais dans ce cas on retombe encore une fois dans les problématiques de nommage et d’organisation du code soulevées dans l’article du créateur de Tailwind. Comment tu assures la réutilisation de tes styles, la non répétition quand tu as un composant qui a presque le même look mais pas totalement et compagnie ? Il y a pas de vraie bonne solution. Perso je sais juste d’expérience que ton système fonctionne pas à grande échelle. :confused:

27

Je ne prétend pas qu’il y a de bonnes solution mais celle proposée par Tailwind ne me convainc pas.

Concernant ta seconde observation, je précise justement qu’il s’agit de certains cas de figures.
Et pour répondre à ta question, j’utilise la surcharge mais pas à un point aussi poussé que Tailwind.

28

vous connaissez ce site ?

Ca présente toutes les trends en CSS et on voit bien que Tailwind et les utility classes ont la côté, mais il n’y a pas que ça. (stateofjs.com existe aussi)

1 « J'aime »
29

Yup, ça fait plusieurs années qu’ils font ça, sur le modèle du même truc en JS. Et c’est très bien ça donne les tendances.

30

oui c’est que je disais dans mon post que tu as lu en diagonale
:kissing_heart:

31

mdr j’avoue, j’ai pas bien lu jusqu’au bout, my bad :sweat_smile: