-
reset
- Elle a d’abord copié environ 200 lignes des preflight styles de Tailwind depuis
tailwind.css
- Elle était habituée depuis longtemps au reset de Tailwind, et la règle qui applique
box-sizing: border-box à tous les éléments fait en sorte que la largeur d’un élément inclut son padding
* { box-sizing: border-box; }
- Il est aussi possible qu’elle dépende inconsciemment d’autres règles de reset comme
html {line-height: 1.5;}, et écrire du CSS sans elles demanderait sans doute une grosse adaptation
-
components
- La majeure partie du CSS est organisée dans des fichiers par composant, un peu comme avec des composants Vue ou React
- Chaque composant possède une classe propre, afin que le CSS d’un composant n’écrase pas celui d’un autre
- En pratique, environ 80 % du CSS qu’elle veut modifier se trouve dans ces fichiers de composants, donc quand elle édite un composant de 100 lignes, elle n’a à penser qu’à ces 100 lignes
- Par exemple, un composant
.zine peut avoir le HTML suivant
<figure class="zine horizontal">
<img src="whatever.jpg">
</figure>
- Le CSS regroupe à l’intérieur du composant les états comme
.horizontal, .vertical et :hover via des sélecteurs imbriqués
.zine {
...
&.horizontal {
...
}
&.vertical {
...
}
&:hover {
...
}
}
- Elle n’a pas mis en place de protection programmatique contre les interférences entre composants comme avec les Web Components ou
@scope, mais le simple fait de définir et respecter des conventions donne déjà l’impression d’un grand progrès
-
colours
colours.css regroupe des variables CSS pouvant être utilisées en cas de besoin- Les couleurs étant difficiles, et comme elle ne voulait pas revoir leur usage dans cette refactorisation, elle a conservé l’approche existante
- La seule règle consiste à lister dans ce fichier toutes les couleurs utilisées sur le site
:root {
--pink: #fea0c2;
--pink-light: #F9B9B9;
--red: #f91a55;
--orange: rgb(222, 117, 31);
...
}
-
font sizes
- Avec Tailwind, il suffisait de choisir un palier comme
text-lg, xl ou 2xl, sans avoir à se souvenir s’il fallait utiliser em, px ou rem
- Pour conserver cela en CSS vanilla, elle a défini des variables de taille reprises de Tailwind
--size-xs: 0.75rem;
--line-height-xs: 1rem;
--size-sm: 0.875rem;
--line-height-sm: 1.25rem;
- Les tailles de police sont définies via des variables ; c’est un peu plus verbeux que Tailwind, mais cela lui convient pour l’instant
h3 {
font-size: var(--size-lg);
line-weight: var(--line-weight-lg);
}
-
utilities
- Les éléments répétés dans plusieurs composants, comme les boutons, sont classés dans les utilities
- Certaines classes utilitaires comme
.sr-only, destinées à des éléments visibles uniquement pour les utilisateurs de lecteurs d’écran, ont été copiées depuis Tailwind
- Elle veut garder cette zone réduite et la modifier avec prudence
-
base
- Les styles “base” sont des styles appliqués directement à l’ensemble du site
- Comme elle n’est pas assez sûre d’elle pour imposer beaucoup de styles à tout le site, cette zone reste très petite
- Pour l’instant, les seules règles qui lui semblent correctes concernent
<section> et a, et la règle sur <section> pourra changer plus tard
/* put a 950px column in the middle of each <section> */
section {
--inner-width: 950px;
padding: 3rem max(1rem, (100% - var(--inner-width))/2);
}
a {
color: var(--orange);
}
- Il semble plus simple de laisser les styles de base presque vides au départ, puis de faire remonter progressivement depuis les composants vers la base ce qu’on souhaite partager, dans une approche bottom-up
-
spacing
- Sa manière de gérer
padding et margin n’est pas encore complètement définie
- Lorsqu’elle utilisait Tailwind, elle ajoutait du padding et des marges un peu partout de manière improvisée jusqu’à obtenir le rendu voulu, et elle cherche maintenant une méthode plus principielle
- Pour l’instant, elle essaie autant que possible de faire porter la responsabilité des espacements aux composants de layout externes
- Lorsqu’on veut espacer uniformément les enfants d’une
<section> qui en contient plusieurs, on peut utiliser la règle suivante
section > *+* {
margin-top: 1rem;
}
-
responsive design
- Avec Tailwind, elle utilisait beaucoup une syntaxe basée sur les media queries comme
md:text-xl, qui applique le style text-xl à partir d’une certaine largeur
- Elle essaie maintenant de construire des layouts CSS grid plus souples, qui nécessitent moins de breakpoints
- Avec
auto-fit, il est possible d’obtenir automatiquement 2 colonnes sur grand écran et 1 colonne sur petit écran
display: grid;
grid-template-columns: repeat(auto-fit, minmax(min(100%, 400px), max-content));
justify-content: center;
-
build system
- Aucun système de build séparé n’est nécessaire pendant le développement
- Le CSS intègre l’instruction
@import, qui permet de découper les fichiers et de les importer
@import "reset.css";
@import "typography.css";
@import "colors.css";
- Le CSS prend aussi en charge les sélecteurs imbriqués
.page {
h2 { ...}
}
- Pour la production, si elle souhaite regrouper les fichiers CSS, elle peut utiliser
esbuild
esbuild style.css --bundle --loader:.svg=dataurl --loader:.woff2=file --outfile=/tmp/out.css
- Elle évite en général d’utiliser des systèmes de build pour le CSS et le JS, mais
esbuild lui paraît acceptable car il repose sur des standards du web et se présente sous la forme d’un binaire Go statique
- Elle a d’ailleurs écrit en 2021 un article sur esbuild et Vue
3 commentaires
Ce n’est pas un peu mieux depuis le passage à une configuration zéro ?
Commentaires sur Hacker News
J’enseigne depuis longtemps le HTML sémantique et le balisage accessible, et j’ai aussi beaucoup travaillé sur des sites et applications pour lecteurs d’écran. Le principal problème de Tailwind, c’est qu’il inverse l’ordre dans lequel on devrait penser le HTML et le CSS
Le HTML sert à exprimer le sens d’un document, donc il faut commencer par là, puis appliquer le style avec le CSS. Si le style exige des éléments supplémentaires, on peut utiliser des
divou desspan, mais il faut d’abord se demander s’il n’existe pas un meilleur élémentTailwind pousse les développeurs vers une approche centrée sur le CSS, au point de leur faire penser d’abord aux classes Tailwind voulues, puis d’ajouter un autre
divdans le DOM juste pour pouvoir y attacher ces classesLes compétences d’un développeur web devraient inclure la capacité à produire un HTML et un CSS lisibles dans le temps, utilisables par tous, et globalement conformes aux spécifications HTML/CSS. Tailwind fait régresser sur ce point. Même le premier exemple sur le site de Tailwind n’emploie que des
divet desspan, ce qui a été une mauvaise formation pour les nouveaux développeurs, et a aussi contribué à la tendance des LLM à recracher de la soupe de div sans consigne explicitediv, et il est injuste de lui attribuer le manque d’intérêt ou de compréhension des développeursN’importe quel outil peut être mal utilisé, et Tailwind ne fait pas exception. J’utilise le CSS depuis environ 20 ans, j’ai aussi pratiqué Less, SASS/SCSS, Stylus et PostCSS, mais si je me suis installé sur Tailwind ces dernières années, c’est justement parce qu’il permet un styling d’application plus robuste
On n’a pas besoin de construire des abstractions excessives autour des styles/classes, mettre les styles directement près du balisage concerné réduit la charge cognitive, limite les changements de style involontaires dus à des sélecteurs trop lâches, et facilite le débogage. Sauf pour des sites/apps très simples, les codebases Tailwind sont souvent moins complexes et moins fragiles que celles qui reposent sur un framework CSS maison
Si on ajoute une échelle cohérente de polices, couleurs et tailles, des bundles plus petits, la cohérence entre développeurs familiers de Tailwind, un écosystème solide et sa compatibilité avec les LLM, c’est un excellent choix pour beaucoup d’équipes. Au final, comme pour la plupart des outils, tout dépend de la personne qui l’utilise
Je vois le chaos HTML/CSS/JS comme un mal nécessaire quand on cible le navigateur, et pour moi ce n’est qu’une couche de présentation. Dans mon travail, je mets bien plus l’accent sur l’exactitude du schéma de base de données ou de la logique métier backend
Si cette couche de présentation un peu sale reste aussi limitée que possible tout en donnant un code à peu près maintenable, ça me suffit, et Tailwind convient bien à cet objectif. Les LLM l’écrivent bien, les nouveaux développeurs le comprennent vite, et c’est aussi assez simple à relire et modifier plus tard
Je suis entièrement d’accord pour dire qu’un projet Tailwind n’est pas la meilleure façon pour un débutant d’apprendre HTML/CSS, mais je préfère encore qu’un débutant se concentre sur de bons schémas de base de données, des API intuitives, une logique métier testable, etc.
Rien dans Tailwind lui-même n’oblige à utiliser des
divet desspanà la place de balises HTML appropriéesUn document et une interface, ce n’est pas la même chose, et Tailwind a beaucoup plus de sens dans une interface. On peut utiliser Tailwind pour l’interface et des sélecteurs HTML à portée limitée pour d’autres contenus
Le fait que Tailwind soit environ 4 fois plus rapide que d’écrire une codebase CSS complexe, avec pratiquement aucun surcoût, reste un avantage quel que soit le jugement qu’on porte sur lui
En résumé, c’est une façon d’écrire le CSS dans l’ordre de spécificité :
/scss/
├── 1-settings. <- paramètres globaux
├── 2-design-tokens <- polices, couleurs, espacements, etc.
├── 3-tools <- mixins Sass, fonctions CSS, etc.
├── 4-generic <- reset, box-sizing, normalisation, etc.
├── 5-elements <- styles de base des titres, boutons, liens
├── 6-skeleton <- grille de mise en page, etc.
├── 7-components <- cartes, carrousels, etc.
├── 8-utilities <- classes utilitaires et helpers
├── _shame.scss <- hacks à corriger plus tard
└── main.scss
ITCSS élimine pratiquement les guerres de spécificité dans une codebase CSS. En général, le seul endroit où apparaît
!important, c’est la couche utilitaire[1] : https://matthiasott.com/notes/how-i-structure-my-css
Si on regarde les bibliothèques de composants, elles incluent aussi des attributs
aria: https://tailwindcss.com/plus/ui-blocks/marketing/sections/pr...Sauf pour quelque chose qui ressemble davantage à une brochure numérique, comme une landing page, je commence toujours par le balisage avant d’ajouter les classes CSS par-dessus
Les deux grands avantages de Tailwind, c’est qu’il y a déjà beaucoup d’informations de classes dans les données d’entraînement des IA, et qu’il n’y a pas de conflits de styles
Du coup, quand une IA crée un nouveau style, elle n’a pas besoin de se référer à une feuille de style existante, ce qui aide pour la gestion du contexte
Avec du CSS personnalisé, l’IA doit lire la feuille de style existante pour réduire les conflits ou les doublons, mais les grosses feuilles de style peuvent consommer beaucoup de mémoire de contexte, ce qui pose problème
J’aime énormément les textes de Julia Evans
Elle écrit depuis un endroit de vulnérabilité et de franchise. Beaucoup écrivent pour avoir l’air intelligents, mais Julia écrit avec l’attitude : « je ne sais pas tout non plus, mais j’ai découvert des choses que j’ai envie de partager ». Même sans la connaître personnellement, on a presque l’impression qu’elle partage quelque chose avec des gens qu’elle aime
Lors de la dernière Strange Loop, elle a présenté avec Randall Munroe ; il y avait des gens qui faisaient la queue pour lui parler après la présentation, mais moi j’attendais pour parler à Julia. Je suis sincèrement désolé, je crois qu’elle n’a pas compris ma blague sur le fait de réécrire les scripts bash en Perl
Je ne suis pas Julia, mais j’ai presque la même philosophie vis-à-vis des interventions publiques et des présentations, et j’essaie aussi de la transmettre aux collègues qui ont du mal avec cet exercice. C’est un grand privilège de pouvoir transmettre à ses collègues et à ses proches un savoir qu’on maîtrise un peu mieux, et qui peut leur être utile
CSS Modules est une solution plus simple aux problèmes de cascade. Il génère des noms de classes uniques pour éviter les collisions [1]
Il n’a pas non plus deux gros défauts de Tailwind : la lisibilité [2] et le support des outils. Je trouve notamment meilleur le support dans Chrome et FireFox DevTools pour déboguer et expérimenter de façon interactive
[1] https://x.com/efortis/status/1888304658080256099
[2] https://github.com/ericfortis/tailwind-eye
Ce qui m’a toujours frappé avec Tailwind, c’est que presque tous les arguments de ses partisans reviennent au fond à dire : « je n’ai jamais appris le CSS au-delà d’un niveau junior »
On entend souvent des choses comme : « sans Tailwind, on va se retrouver avec un énorme fichier CSS désordonné qui grossit sans contrôle, plein de vieux code et de
!important», mais le CSS est une compétence comme les autresSi on en apprend juste assez pour obtenir le bon rendu à l’écran et bricoler, l’ambition dépasse très vite la capacité à garder le code propre
C’est vraiment frustrant de parler de Tailwind et de CSS avec quelqu’un, puis de réaliser qu’il ne sait même pas ce que veut dire « cascade », et n’a même jamais envisagé que ce concept puisse être utile dans le contexte d’une feuille de style
J’utilise beaucoup le CSS depuis les années 90, j’ai regardé Tailwind, et une fois que j’ai compris le principe, j’ai commencé à éviter le CSS pur la plupart du temps. D’une certaine manière, c’est remplacer un bazar par un autre, mais personnellement je préfère gérer une soupe de classes localisée qu’une cascade qui se chevauche et se contredit à travers plusieurs fichiers
On peut faire proprement dans les deux cas, mais remettre de l’ordre dans un bazar Tailwind me paraît bien préférable à remettre de l’ordre dans un bazar CSS, et l’ensemble du processus de développement me semble aussi plus agréable
Moi-même, je programme depuis plus de 20 ans et je fais du développement web depuis presque 15 ans, mais j’ai du mal à trouver la motivation pour vraiment apprendre le CSS. Il y a trop de compétences techniques à suivre, et le CSS est assez bas dans mes priorités
Je préférerais laisser ça à des spécialistes, mais les entreprises ne veulent pas embaucher de développeurs front-end dédiés
J’écris un guide de développement web propre centré sur l’écriture d’un HTML et d’un CSS qui passent bien à l’échelle : https://webdev.bryanhogan.com/
Ça pourra peut-être être utile à certaines personnes ici. Pour le styling, je n’utilise rien comme Tailwind, seulement des frameworks modernes comme Astro ou Svelte et du CSS
Dans tous mes projets, j’ai
reset.css,var.css,global.css,util.css, et je limite ensuite le reste des styles au composant ou à la mise en page concernéeBon article
J’aime supprimer les dépendances à des bibliothèques externes et construire mes solutions moi-même à partir de zéro, mais il y a une raison claire pour laquelle j’ai décidé de ne pas faire ça avec Tailwind : il fournit une optimisation de production qui garantit qu’on ne déploie que le minimum de CSS réellement nécessaire
Même si on énumère dans
globals.cssou ailleurs toutes les options de couleurs, d’espacement, etc., on n’a pas besoin de se demander si toutes ces variantes seront utilisées en production. Quand on travaille dans un framework comme Next.js, cette étape de minimisation se fait même automatiquement au build, et rien que ça constitue une raison suffisante pour moi de ne pas quitter TailwindJe n’ai jamais eu le sentiment de subir des contraintes ingérables en écrivant du CSS inline avec Tailwind, et je n’ai pas non plus eu de gros problème à implémenter des grilles réactives qui s’adaptent à la largeur de l’écran avec ses outils de grille. J’ai déjà résolu tous les scénarios évoqués dans l’article avec Tailwind, ou avec une combinaison Tailwind + CSS. Il est vrai que
grid-column-areasn’existe pas par défaut, mais jusqu’ici je ne l’ai jamais ressenti comme une contrainte majeure dans des layouts de grilles responsivesLe plus gros problème de Tailwind, c’est qu’il faut du temps pour s’habituer à le lire. On apprend que le CSS inline est mauvais et que le CSS à portée globale est bon, et on s’habitue à un HTML propre ; du coup, du vrai code Tailwind, surtout quand les lignes sont longues, paraît vraiment difficile à lire au début. Avec le temps, je me suis complètement habitué à cet aspect, et j’en suis finalement arrivé à la conclusion que, pour moi, Tailwind est plus efficace, plus maintenable, et même plus lisible, mais ça a pris un bon moment
L’approche que j’aime vraiment en ce moment, c’est d’utiliser Tailwind avec des styles à portée limitée (dans Svelte et Vue)
Ça permet de conserver le confort de Tailwind tout en limitant au maximum la pollution des templates :
+
{{ count }}
Pour moi, Svelte et les LLM ont complètement supprimé la nécessité de Tailwind
Je me suis rendu compte que si j’utilisais surtout Tailwind, ce n’était pas à cause des contraintes que je m’imposais, mais pour éviter les conflits CSS et parce que sa syntaxe me paraissait plus logique
Le meilleur aspect de Tailwind, à mes yeux, c’est qu’il n’y a pas besoin d’inventer des noms de classes temporaires. Plus besoin d’utiliser BEM
Avis sur Lobste.rs
Pour mes projets personnels, je n’utilise presque plus de frameworks CSS/JavaScript
Sans dépendances, il ne peut pas y avoir de vulnérabilités de supply chain. Bien sûr, ce n’est pas le seul type de vulnérabilité, mais ça aide
C’est le résultat combiné de la fatigue des frameworks, de la surcharge de
npm audit, et du fait qu’avec les LLM je me soucie moins du jugement des autres sur la manière d’implémenter les choses. Par exemple, des questions du genre « pourquoi tu n’utilises pas React et Tailwind ? »C’est simplement comme ça que CSS fonctionne
Quand je vois des gens utiliser Tailwind aveuglément sans comprendre ça, j’ai envie de sortir crier sur les nuages. À mes yeux, 90 % de Tailwind, c’est du style inline avec une syntaxe différente, à peine une étape au-dessus de la balise
<FONT>Ce billet de blog explique des choses que j’avais réellement besoin de comprendre
Tailwind fonctionne assez différemment du style inline, et se rapproche bien davantage de CSS. Comme le souligne l’article, une bonne partie des bonnes habitudes qui permettent de bien utiliser Tailwind sont aussi nécessaires pour écrire un CSS efficace. Tailwind se rapproche davantage du fait d’attacher à chaque élément un bloc CSS avec une portée implicite, tout en utilisant un DSL particulier
Je comprends très bien le fonctionnement de CSS, mais le CSS natif reste lourd pour moi, et je ne suis pas très bon non plus en design graphique, donc j’utilise toujours Tailwind. Cet article propose des idées pour structurer son CSS en partant de Tailwind
En tant que personne qui n’a pas très bien suivi les tendances récentes, j’ai l’impression que cet article montre assez bien les pratiques CSS modernes
J’aime aussi le fait qu’il contienne beaucoup de liens vers des articles qui l’ont inspiré. Ça a l’air d’être une bonne lecture, et pour l’instant je n’ai lu que "no outer margin"
En revanche, je reste un peu sceptique sur l’approche qui consiste à définir les styles de base « de bas en haut ». Je ne sais pas vraiment quoi faire d’autre, et ça mérite peut-être d’être essayé, mais les styles de base sont fondamentalement délicats
J’ai vraiment beaucoup aimé cet article
Moi aussi, j’ai appris CSS progressivement en bricolant plein de petits sites, et je pense que ça m’aurait aidé d’avoir dès le départ une approche aussi systémique. J’ai une certaine aversion pour les frameworks, mais à force de ne pas en utiliser, même si je sais implémenter ce que je veux, j’ai souvent l’impression de flotter dans le vide sans structure
J’aime bien que le message ne soit pas « Tailwind est mauvais, utilisez simplement CSS », mais plutôt « Tailwind est excellent, mais il n’est peut-être plus nécessaire aujourd’hui »
J’ai toujours eu du mal à structurer mon CSS à la main, et cet article m’a vraiment fait réfléchir d’une manière très différente
Cette technique de structuration m’a été assez utile pour organiser mon CSS : https://rstacruz.github.io/rscss/
Globalement, ça va bien avec ce que jvns explique dans l’article d’origine, en y ajoutant un peu plus de structure et d’organisation