Cette captation vidéo qui dure 1 heure et 10 minutes comporte la présentation et les questions posées par le public.
Tout dans le HTML, facile à éditer mais limites vite atteintes : duplication (font…)
Possibilité de généraliser des styles, supprimer la duplication. Principalement utilisé sur les tags, des classes “présentation” (sidebar-left, menu-top…) et avec des cascades.
On nous dit : ce n’est pas sémantique, si je déplace ma sidebar je dois changer sa classe.
Utilisation principalement de classes, avec des noms “sémantiques” plus que “présentation” : “topics-list”, “topic-preview”…
Problème : trouver des noms, et devoir toucher au CSS dès qu’on ajoute des éléments : tout est “sémantique”, doit donc avoir une existence, donc être nommé spécifiquement, cela complexifie la réutilisation du code (“news-list”, “news-preview”).
Idéal : CSS Zen Garden, changer uniquement le CSS sans toucher au HTML.
En pratique : difficile de prévoir un HTML “future proof” qui n’aura pas besoin de modifications. Plus on s’approche d’applications web, plus le CSS et le HTML évoluent en même temps. Certaines modifications ne sont possibles qu’en touchant au HTML, ou au prix de CSS complexe et difficile à maintenir.
La révélation :
Clearfix
Float-left…
Possibilité de factoriser le code pour faciliter la maintenance, mais duplication dans le CSS final si mal utilisé (extend vs include en sass) ou non proposé par le préprocesseur.
Principal avantage : pouvoir réutiliser du code (“button”, “panel”…). Beaucoup de composants préfaits, gain de temps.
Problèmes :
lourd à charger
On nous dit : ce n’est pas “sémantique”
Dépendance à un outil externe
Parti pris visuel, on passe plus de temps à annuler le design qu’à mettre le nôtre => Syndrôme “tous les sites sont identiques”
Ceci étant, parfait pour des interfaces back-office. Évolution sur les versions récentes (Bootstrap 4 : config, migration vers une méthode “utility first”)
CSS existant dur à réutiliser, syndrôme du “je ne fais qu’ajouter en bas du fichier”.
Avènement des applications web : conception en composants. Titres, listes, media object…
Séparer la structure et le style, le contenant et le contenu.
Apparition de pratiques comme “ne pas utiliser les IDs”, “ne pas utiliser les tags”.
Ne pas faire de CSS pour ajouter de nouvelles pages.
Sorte d’optimisation des frameworks : faire son propre Bootstrap. Problème : chronophage, syndrôme NIH
Problème : legos first. Très difficile de concevoir un design en partant de la brique la plus petite (par ex. heading).
Catégorisation des règles CSS
Base
Layout
Module
State
Theme
Problème : retrouver d’un coup le style complet des états d’un composant oblige a avoir plusieurs fichiers
Utilisation d’IDs, de tags, de cascade
Conçu au départ pour concevoir des composants HTML / CSS / JS autonomes
Évite la spécialisation, les problèmes dûs à la cascade
Peut s’utiliser conjointement à d’autres méthodes
On a conservé la partie convention de nommage pour nos composants
Mélange oocss (composants) smacss (organisation) et BEM (nommage)
Brad Frost / Pattern Lab : outil spécifique pour gérer le styleguide et les composants, on n’a pas trouvé comment le réutiliser efficacement
Analogie de nom (atom, molecule etc) difficile à utiliser
Manière d’organiser le code, un peu comme SMACSS. Utilisé avec BEM. Se sert des préprocesseurs pour générer des classes et leurs propriétés en fonction de valeurs de configuration.
On s’en est servi longtemps via InuitCSS de Harry Roberts.
Problèmes principaux qui nous ont fait chercher une alternative :
Pas de documentation, il faut lire le code
Plugin flexbox limité
Pas possible de réutiliser les classes utilitaires dans des composants
Possibilité de connaître le résultat en lisant le HTML
Pas besoin de toucher au CSS
Des développeurs non front peuvent monter des pages à l’aide d’un style guide
Legos : peut construire des maquettes à l’aide des pièces sans savoir fabriquer les pièces
Possibilité de concevoir un design “entier”, puis de le monter avec des classes utilitaires : couleur, espacement, taille…
Utilisation dans une équipe
Base de travail commune, pas de problème avec les habitudes de chacun
Documentation
Réutilisable sur plusieurs projets
“Masquage” de la complexité. Par ex: clearfix, flexbox…
Concept de prog fonctionnelle : voir les classes utilitaires comme des fonctions faisant 1 chose chacune. Abstraction en une classe composant == composition de fonctions. Voir les appels dans le HTML comme une succession de fonctions.
Résultats prédictibles
Inline styles
Separation of concerns
Question de la dépendance du code : html => css ou css =>html
Cf. https://adamwathan.me/css-utility-classes-and-separation-of-concerns/ « Separation of concerns » is a straw man
https://wentsch.me/2019/02/frontend-meetup-utility-first-css-with-tailwind/
HTML bloat
=> tailwind permet d’extraire plusieurs classes utilitaires dans une classe “module”. À utiliser quand on est sûr de sa réutilisabilité. Duplication is far cheaper than the wrong abstraction (Sandi Metz). D’autant plus en front où arrive toujours le cas où on change ici mais pas là
Unmaintainable
Not how you write CSS
You end up with plenty of unused CSS
Lourd quand on charge tout :
config (n’inclure que le strict nécessaire). Tailwind, 600 ko de base, 100 après épuration
Purgecss : 20ko. Attention aux CMS avec des classes en base. Nécessite parfois d’adapter le code (pas de concaténation, pas gênant car pas forcément une bonne pratique : pas possible de rechercher toutes les utilisations d’une classe)
Utility classes should be used along with components
It makes redesigning/theming a nightmare
TailwindCSS, Bulma, Tachyons, PureCSS…
Même nom pour les classes utilitaires et @apply.
Construire avec des utilities
Trouver des patterns réutilisables
Abstraire dans des composants
Sass, Stylus, Less, sans préprocesseur…
Il est possible de créer soi-même des plugins, des variantes. Par exemple : formulaires, animations… Il existe d’ailleurs un plugin pour les formulaires.
Possibilité de changer les noms des classes, les valeurs de chaque variante. Attention au fait que ça limite la possibilité d’utiliser la documentation.
Elle comporte des exemples pour tous les utilitaires, avec des explications. Tout est indexé, le moteur de recherche est efficace. Elle est tellement complète qu’on peut se passer d’un styleguide pour toute la partie utilitaire, seuls les composants créés pour l’application peuvent en nécessiter un.