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) :
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.
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.
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)
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 :
Perso j’utilise auto-close-tags sur Vscode pour auto-fermer parce que comme toi j’ai la flemme de ouf. 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.
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.
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)
Bon j’ai testé viteuf Tailwind en essayant de refaire un site existant. Voila viteuf mes retours :
Tailwind est livré sans système de build, il faut donc passer par postcss, et voir comment intégrer postcss dans son build. Pour ma part j’avais parcel et évidemment… les conflits ont commencé entre versions et consorts. A la fin j’ai fait un script en bash qui reload et rebuild en passant via une commande post-css, c’est le plus simple.
Tailwind crée un fichier de config qui comprend, en gros, le thème du site qu’on fait. Il est possible d’importer le fichier complet de tailwind pour avoir par exemple toutes les classes utilitaires type marge, padding, etc… Au début j’avais un fichier vide et j’ajoutais au fur et à mesure. Mais je trouvais ça pénible en allant au fur et à mesure parce que même si c’est facile, j’ai en fait pas de design system sous les yeux, donc j’ai mis le fichier de base complet. Par contre si j’avais eu une vraie charte graphique, je pense que j’aurais commencé par refaire tout dedans et j’aurais kiffé après.
La gestion du responsive et des states est vraiment cool. Comme c’est mobile first et qu’on a des classes utilitaires, on fait finalement des micro-ajustements ici et là et ça va très vite. J’aime beaucoup notamment pour les states.
Le truc dont on avait parlé ici, le fait qu’on ne peut pas improviser du style (en mettant une classe inexistante dans le fichier de conf) est vraiment un plus je trouve. Plusieurs fois j’ai essayé de tricher mais ça m’a surtout mis sous les yeux que ici et là j’avais improvisé du code ou triché. J’aime bien cette contrainte.
J’ai pas été plus loin que refaire la navigation. Je sais pas si je vais continuer par contre, le site existe et fonctionne actuellement donc le refaire me donne un sentiment de perte de temps. Cependant j’aimerais bien faire un nouveau projet avec.
Bon sinon après avoir testé tailwind j’ai eu envie de me refaire un peu d’histoire des méthodologies CSS pour voir si Wathan bullshitait de ouf ou pas, et j’ai écrit un roman sur l’histoire des méthodologies CSS.
Je suis tombé au passage sur CUBE qui m’a franchement plus hypé que tailwind :
Et sur every layout qui m’a foutu un petit coup de pied dans ma manière d’aborder certains layouts.
Grâce à Stackoverflow je suis tombé sur l’extension « CSS Used », n’existant que sous Chrome, permettant de recopier d’un coup tout les css de l’élément sélectionné.
Ça m’a permis de récupérer les class de mon menu de mon gros projet R Shiny pour l’utiliser dans mon projet Flask VueJs, ceci sans devoir retrouver la génération exacte de bootstrap utilisée.
Donc d’installer dans Vue 3 ~09/2020 la même version générique bootsrap que ma version de R Shiny, à savoir la 3.* ^^’, puis de charger le copier-coller « CSS Used », correspondant à leurs adaptations, puis mon propre css que j’avais créé dans mon projet R Shiny. L’apparence et le fonctionnement sont strictement identiques. Yes !
En utilisant un bootstrap trop récent j’avais des soucis entre le bootstrap.min.js récent et les classes css en version bootstrap 3 (~2013) du R Shiny 1.6 utilisé.
PS : Bootstrap 4 ~10/2014 n’est géré que depuis R Shiny 1.6 ~01/2021 or mon projet a été démarré début 2018 en R Shiny 1.0.5 ~08/2017. Bootstrap 5 vient à peine de sortir ~05/2021.
J’ai finalement réussi à passer en bootsrap 4 avec la même méthode de copier-coller avec « CSS Used», pour que le menu ait la même tête, mais:
en changeant, uniquement dans le menu, les display : flex;, manifestement rajoutés en boostrap 4, par des display : block;, (c’était la cause principale du souci)
en remettant un padding: absolute; dans le .navbar-nav .dropdown-menu
en remettant la bonne couleur de focus qui visiblement est passée de la class open à show.
Et visiblement le bootstrap.min.js suit.
Édit :
Mais bon finalement j’ai refais mon menu en bootsrap 4 navbar sans mes fichiers intermédiaires, sauf mes petites modifs de style, et c’est à 90% identique à mon menu shiny 1.6.0.
Grace à cette page qui contenait le même style que j’utilisais.
)
. Même avec un système comme ça, tu peux avoir du code crade et illisible.
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.
