Méthode Daisy, pour du CSS modulaire
▻http://daisy.tetue.net
Plus personne aujourd’hui n’est seul·e à produire son CSS : outil de publication, plugins, intervenants différents… Les styles en vigueur sur un projet ont plusieurs origines. Pragmatique, la méthode Daisy leur donne successivement la main :
1. posons d’abord la base CSS,
2. puis laissons passer les plugins additionnels,
3. et reprennons la main, en dernier, pour définir nos styles spécifiques.
Quand on travaille en pré-processeur, il semblerait que 1 et 2 soit entièrement inversé. En effet, en pré-proc on génère un thème en utilisant des frameworks et des modules. Ce qui est dans 3, utilise ce qui est dans 1 en l’incluant directement afin de pouvoir l’utiliser (par exemple avec @extend). « theme.scss » inclut les trucs de 1.
Or ce qui est dans 2 est ajouté automatiquement par le CMS ou autre outil, de manière externe à la construction du thème. Le 2 est hors pré-proc et a sa propre vie, développé par d’autres et inséré automatiquement.
Ce qui fait qu’on a alors plutôt 2 / 1 / 3, avec 3 incluant 1 en son début.
<head>
- feuilles insérés par le CMS
- theme.css généré par agrégation, incluant 1 en son début
</head>
Je précise que je parle de ça car la documentation évoque le cas du « pré-processing » :
Daisy s’utilise de façon progressive, sur mesure : en feuille unique, en trois feuilles, ou en framework CSS multi-feuilles (avec ou sans concaténation, preprocessing , etc.)
Et donc je commente uniquement ce cas-là. Et même plus précisément en fait : je commente uniquement le cas où on utilise pré-processeur ET un CMS qui ajoute des choses.
Le thème (en 3) n’a pas à inclure la base (= 1), jamais, celle-ci devant passer avant (en 2) les outils (dont CMS) et divers plugins.
La méthode Daisy décrit ce qui se joue dans le navigateur (du CSS donc), quelque soit la façon de le produire (avec ou sans preprocessing).
En cas d’utilisation avec preprocessing, la personnalisation ne se fait plus seulement en 3 (par surcharge CSS), effectivement, mais aussi sur la base, par paramétrage, des variables. En revanche, il n’y a aucune bonne raison d’intervertir l’ordre d’appel dans le navigateur.
J’ai pourtant tenté de l’expliquer : en pré-processing, le thème (les choix personnels pour tel ou tel élément) peuvent appeler un ou plusieurs styles définis dans les feuilles du 1. C’est même une bonne pratique pour ne pas redéfinir des styles similaires en plusieurs endroits.
Par exemple si on choisit graphiquement d’afficher tel lien précis « comme un bouton », alors on va dire .bloc_truc a{ @extend .button; }. Ce choix personnel peut changer plus tard si on pense que graphiquement ou ergonomiquement ça ne va pas, c’est donc bien dans « theme.css » (3), en revanche la définition générique d’un bouton, c’est bien dans 1. Or pour pouvoir utiliser ce code, tout ce qui est dans 1 doit être importé (@import) au début de 3. Sinon c’est inutilisable et le pré-processing ne sert à rien.