SPIP est distribué avec un jeu de squelettes par défaut, habillé de plusieurs feuilles de style, qui étaient, historiquement (du moins en SPIP 1.8.3) : « spip_style.css », « typographie.css », « habillage.css » et « impression.css ».
J’ai toujours pensé qu’il était plus simple, pour les débutants et autres spipmestres amateurs de s’y retrouver dans une feuille de style unique plutôt que dans plusieurs. C’est donc ce que j’avais préparé pour la dist de SPIP 1.9, avec une feuille unique « habillage.css ». Mais il a fallu maintenir « spip_style.css » à part, pour rétrocompatibilité, parce que plusieurs l’utilisaient telle quelle. Si bien qu’en comptant celle pour l’impression, il restait quand même trois feuilles.
L’arrivée des plugins a posé certains problèmes, très intéressants. Et a tout compliqué. Ceux-ci apportent des éléments, fonctionnalités, squelettes, etc. qui ont besoin d’être habillés de CSS. Le tout est injecté en dernier via #INSERT_HEAD, ce qui passe par dessus les styles définis par le webmestre… de quoi le rendre fou. Car l’ordre dans lequel sont appelées les feuilles de style est important (cf. règle de la cascade) : c’est la déclaration qui intervient en dernier qui l’emporte.
Chacun son tour…
C’est pourquoi la balise #INSERT_HEAD_CSS a été introduite (en révision 15217) : pour injecter les feuilles de style plus tôt et laisser le webmestre passer avant et après. Avant, pour poser les fondations — via un « reset » (ou plus). Et après, pour avoir le dernier mot. Au milieu, les feuilles de style insérées par les plugins, innombrables et variables, imprévisibles, n’ont plus qu’à bien se tenir.
Cet ordre d’appel en trois temps, chacun son tour, est inévitable dans les projets modulaires que sont désormais les sites SPIP. C’est le principe fondamental de la méthode Daisy, qui est appliquée à SPIP 2 via le plugin « Base CSS » et dans la version actuellement en développement de SPIP 3, apportant un changement considérable. Ça se présente comme un « framework » — qui pose un socle CSS en plusieurs feuilles : « reset.css », « typo.css », « spip.css », « layout.css », etc. — où chaque feuille peut être remplacée par celle, homonyme, d’un autre framework CSS, pour plus de liberté et de plaisir.
Combien de feuilles de style dans la prochaine « dist » ?
Si l’approche est la bonne, nécessaire, elle reste peut-être complexe et d’un abord difficile. Car nous sommes loin de la feuille de style unique ! Comment simplifier ?
