CSS - Le topic des mecs qui ont la .class

Dev
1

Sur notre projet on est en train d’envisager un passage de bootstrap à Tailwind. Je ne sais pas si vous connaissez ?

Attention ce n’est pas du tout comparable à Bootstrap! Tailwind c’est un framework qui n’est composé que de classes utilitaires. Par exemple py-10 veut dire "ajouter 10 pixels de padding sur l’axe vertical.

Autrement dit Tailwind n’est pas pour des gens qui ne savent pas faire du html/css, c’est l’inverse complet : il est pour ceux qui sont à un stade avancé et ont exploré la plupart des soucis liés à l’organisation du CSS et de ses problèmes de sémantique. Si vous avez un peu de temps, cet article explique très bien la chose :

Du coup Tailwind ne vous donne pas de composants tout fait comme Bootstrap. Les auteurs de Tailwind ont bien créé Tailwind UI qui est un équivalent à Bootstrap utilisant Tailwind, mais cela ne change rien au fait qu’il faut aussi connaître le CSS et Tailwind pour le customiser. De plus ce n’est pas gratuit (150 dollars minimum) et c’est toujours en early access.

Les raisons pour lesquelles beaucoup passent sur Tailwind c’est que Tailwind force à la cohérence graphique en ne donnant que des valeurs prédéfinies via des classes utilitaires. Le but avec Tailwind ce n’est pas vraiment de faire des templates HTML classiques (quoique c’est parfaitement possible) car que ce sera verbeux, répétitif et moche à lire. Le but de Tailwind c’est de bosser par composants et dans ces composants, d’éviter que quelqu’un improvise une taille de font ou de padding, tout en s’affranchissant des problématiques de nommage et de sémantique.

Je vais probablement tester Tailwind bientot pour un projet aussi, mais je fais du CSS depuis 5 ans. Si vous êtes moyen surs de vos compétences en CSS, vaut mieux rester sur du bootstrap et prendre une implémentation avec le framework de votre choix.

SI vous voulez une liste de frameworks ou librairies alternatives à Vue/React/Angular allez jetez un oeil sur cette page où j’en ai liste pas mal.

7 « J'aime »
2

Un message a été fusionné à un sujet existant : Symfony ou Django ou Flask? Angular/React/Vuejs/Stimulus?

3

@Thomasorus a bien expliqué pourquoi on pourrait switcher sur tailwindcss
on a déjà tenté pas mal de façon d’organiser notre code css, d’améliorer l’encapsulation et la réutilisation (BEM …) et on arrive jamais à rien de probant (alors qu’en code classique on y arrive)

Du coup Tailwind arrive avec une façon complètement différente d’aborder le problème, en disant grosso modo : avec CSS c’est la merde, ya aucune solution fonctionne. Du coup, YOLO on fait plus de CSS et on met tout dans le HTML avec plein de petites utility classes.

Et comment on fait du coup pour pas passer notre vie à copier/coller les meme classes CSS : et bien au lieu de faire nos propres fichiers CSS comme on en a l’habitude, Tailwind suggère d’utiliser les fonctionnalités de composant offertes par bcp de librairies UI (comme vue.js ou React)

L’impasse des solutions à base de CSS a touché une corde chez moi, du coup même si je ne suis pas encore convaincu à 100%, je me dis pourquoi pas et je vais tenter le coup :slight_smile:

3 « J'aime »
4

Il me semble que c’est une hérésie pour les graphistes Web.

1 « J'aime »
5

pour moi aussi ca me semblait une hérésie

Et puis en lisant la documentation de tailwind et l’article de blog listé sur leur homepage j’ai vu que les gars étaient allés beaucoup plus loin que moi en CSS et étaient arrivés à une impasse, donc au final pourquoi pas tenter autre chose :slight_smile:

L’article en question : CSS Utility Classes and "Separation of Concerns"

1 « J'aime »
6

Je vais mettre mon petit grain de sel mais pour moi aussi Tailwind est un non sens absolu.

Il n’a rien résolu. Et je n’aime pas non plus cette approche du CSS avec les ___ ça embrouille le code et comme il le dit lui même on se retrouve avec des class qui font la même chose à l’infini.
Je préfère 100 fois avoir une class parent qui va déterminer le style des éléments enfants pour les cas particuliers.
Pour le reste, j’ai des class génériques qui vont déterminer par ex la typo, sa couleur et sa taille et on a pas besoin de le redéfinir je ne sais combien de fois dans la page.

Et si par hasard j’ai besoin d’un style souvent utilisé mais pas de manière systématique, faire une petite class en plus pour ce cas là, ça suffit largement (et encore).

Et au final, il reproduit ce que lui même dénonce et on se retrouve avec une tripotée de class css car tout devient un cas particulier avec son système : et un code HTML difficilement lisible et difficilement maintenable.

Ça revient à faire du style à l’ancienne avec l’attribut « style= … » sur chaque balise. C’est un gros retour en arrière sous couvert de quelque chose de « moderne ».
Le problème vient aussi du fait que très souvent les développeurs ne connaissent que très mal le css et ne le comprennent pas (et globalement ça les saoule au plus haut point).

Sauf si… j’ai raté un truc mais franchement, je ne comprend pas l’intérêt de sa solution à un problème qui n’existe pas.

1 « J'aime »
7

Hé les autres graphistes :slight_smile: : vous en pensez quoi de Tailwindcss qui a une façon de voir… pas très pratique pour les graphistes.

@cedric et @titan

8

Ben en fait la solution qu’ils proposent c’est d’utiliser les fonctionnalités composant proposées par de nombreux frameworks UI pour construire une bibliothèque de composants déjà stylés. Allez voir la section « Worried about duplication? Don’t be » de leur homepage.

9

c’est pas tellement un problème de graphiste mais davantage un problème d’intégrateur (celui qui style les écrans codés à partir des maquettes fournies par les graphiste). Et je connais maintenant pas mal d’intégrateurs qui ont étoffé leurs compétences avec un minimum de compétences JS / React

10

Oui mais ça ne change pas grand chose au problème de se retrouver avec une foultitude de class sur une balise : maintenance compliqué, code HTML difficile à lire car surchargé (inutilement).

11

Oui je comprends bien la crainte (que j’ai aussi en partie). J’en dirai plus quand je me serai fait un vrais avis.

Pour ce qui est de la maintenance, quand je vois la tête de mes fichiers CSS c’est pas génial … On fait toujours un arbitrage entre isolation (pour qu’une modif de style sur un écran ne fasse pas péter un autre écran à l’autre bout de l’app) et réutilisabilité (pour ne pas se taper toujours les même styles et avoir un style homogène dans toute l’app). Pour nous (je ne dis pas que c’est impossible juste que je n’ai jamais réussi), on n’arrive pas à produire du CSS bien isolé et hautement réutilisable … du coup une approche alternative m’intrigue :slight_smile:

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 »