Pourquoi du LESS

Le CSS est un langage déclaratif simple : la plupart du temps, on applique une valeur à une propriété. Mais de nos jours, avec le développement des attributs propriétaires mozilla ou webkit le code se trouve dupliqué en de nombreux endroits. En outre, il est est impossible d’imbriquer des sélecteurs en CSS pour éviter les répétitions de code. Enfin, il est impossible de paramétrer les styles comme les couleurs par exemple et ainsi d’en changer facilement de façon cohérente dans l’ensemble du site.
Avec SPIP la paramétrage des CSS est déjà possible en utilisant les variables de configuration et des fichiers CSS dynamiques au format HTML. De même, Arno* avait aussi fait avancer l’écriture des CSS avec le plugin « CSS imbriqués ». Néanmoins, il n’existait rien de standard.

C’est ainsi que sont nés les pré-processeurs LESS ou SASS, pour combler ses manques et apporter aussi d’autres fonctionnalités de type programmatique. Même si il est toujours possible de se passer de ces pré-processeurs, j’ai eu envie d’intégrer cette méthode dans mon squelette au moins comme une « proof of concept » et un apprentissage.

Intégrer les fichiers LESS de TinyTypo

TinyTypo est par défaut développée en LESS. Il suffit donc de récupérer les sources LESS et de les recopier dans un dossier less/ à la racine du squelette. La compilation de ces fichiers fournira les fichiers CSS dans le dossier css/.
Les variables de Tiny Typo sont définies dans le fichier var.less. On le renomme var_tinytypo.less en n’oubliant pas de le faire dans chacun des fichiers LESS de Tiny Typo. En effet, on gardera chaque ensemble de variables dans un fichier séparé. Je ne sais pas si cela est la meilleure approche mais ça permettra dans un premier temps de distinguer l’utilisation des variables.

On utilise donc une version un peu modifiée de Tiny Typo mais cela reste très maitrisable surtout quand on pense que seuls les fichiers LESS seront maintenant nécessaires.

Passer les styles de boites sous LESS

Pour migrer vers des sources en LESS nous allons procéder par étapes. La prmière sera d’utiliser un outil web CSS 2 LESS qui permet de créer un fichier LESS à partir d’un fichier CSS. Bien entendu, ce fichier n’est pas optimisé mais l’utilisation de ce service web va éviter de tâtonner à partir de notre CSS. Le service se contente de créer les règles imbriquées et certaines variables automatiquement.

Fichier css/box.css

On copie le contenu du fichier dans le bloc de gauche de la page de conversion du service CSS 2 LESS et on récupère le contenu LESS dans le bloc de droite. On crée un fichier box.less avec le contenu ainsi obtenu [1].

On liste les règles identiques et on les écrit sur une même ligne comme suit :

Pour les règles vides, il faut insérer un commentaire afin qu’elles soient conservées suite à la compilation :

Ensuite, on crée une mixin avec deux paramètres top-corner() pour le bloc de 4 règles utilisés deux fois dans les classes .tr et .tl des boites de classe .complex. Ce n’est pas vital dans ce cas mais cela permet de se familiariser avec les concepts de LESS. Cette mixin ne produit pas de règle CSS .top-corner. On obtient :

Maintenant, le plus compliqué est de définir le paramétrage que l’on souhaite fournir à notre système de boites. Il faut éviter la tentation du tout paramètre et surtout détecter la cohérence entre deux valeurs pour savoir si elles doivent ou pas partager la même variable LESS. L’outil CCS 2 LESS fait déjà une partie du travail en détectant les valeurs identiques utilisées plusieurs fois avec la même propriété mais cela reste notoirement insuffisant.

Les variables ainsi définies sont isolées dans un fichier less/var_box.less et on rajoute une directive @import dans le fichier less/box.less.

Fichier css/box_skins.css

On renouvelle les opérations précédentes sur ce fichier. C’est bien entendu le plus intéressant car comme son nom l’indique il est destiné à personnaliser l’habillage des boites. On obtient un code propre et correctement paramétré. Je me suis principalement attaché à paramétrer les boites d’alerte, les autres étant moins utilisées dans l’espace public.

Pour les boites d’alerte, on reproduit la méthode de Bootstrap, à savoir, définir les couleurs du texte à partir de la couleur du fond. Pour cela les fonctions LESS darken() et spin() sont parfaitement adaptées. On fait de même avec la couleur du fond d’un lien lors de son survol en utilisant la fonction lighten().

Conclusion

La liste des variables est assez important et on aurait sans doute pu limiter un peu le nombre surtout pour la structure des boites. Mais finalement ça ne coute pas grand chose du fait de la compilation.

Les layouts Gala en LESS

Il y a 40 layouts Gala que l’on peut scinder en 2 catégories : les layouts à 3 colonnes et les layouts à 2 colonnes. Pour chacune de ces catégories on distingue des sous-catégories selon que la structure est fixe, fluide ou hybride. On obtient ainsi :

• Layouts à 3 colonnes :
  • de 1 à 6, la page est fluide, toutes les colonnes sont fluides et exprimées en pourcentage ;
  • de 7 à 12, la page est fixe, toutes les colonnes sont fixes et exprimées en pixels ;
  • de 13 à 18, la page est fluide, les colonnes aside et extra sont fixes et exprimées en pixels ;
  • de 19 à 22, la page est fluide, les colonnes aside et extra sont soit fixes et exprimées en pixels, soit fluides et exprimées en pourcentage ;
• Layouts à 2 colonnes
  • de 23 à 24, la page est fluide, les colonnes aside et extra sont fixes et exprimées en pixels ;
  • de 25 à 26, la page est fluide, les colonnes aside et extra sont fluides aussi et exprimées en pourcentage ;
  • de 27 à 28, la page est fluide, la colonne content prend toute la largeur et les colonnes aside et extra se répartissent la largeur sous content ;
  • de 29 à 30, la page est fluide, la colonne aside est fluide aussi et exprimée en pourcentage et la colonne extra prend toute la largeur sous content ;
  • de 31 à 32, la page est fluide, la colonne aside est fixe et exprimée en pixels et la colonne extra prend toute la largeur sous content ;
  • de 33 à 34, la page est fixe, toutes les colonnes sont fixes et exprimées en pixels ;
  • de 35 à 38, la page est fixe, toutes les colonnes sont fixes et exprimées en pixels et la colonne extra est sous la colonne content avec la même largeur ;
  • de 39 à 40, la page est fixe, la colonne content prend toute la largeur et les colonnes aside et extra se répartissent la largeur sous content ;

Quand on étudie la structure des CSS on imagine qu’il existe forcément une fonction qui permettrait de calculer l’ensemble des layouts à partir de paramètres comme la largeur des colonnes, la fluidité, la position des colonnes, etc. Mais en cherchant un peu elle apparait bien vite très complexe.

Même avec les fonctionnalité « programmatiques » de LESS cette fonction semble très difficile à mettre en oeuvre. Parfois on a l’impression qu’il faut factoriser le code à l’intérieur d’une même sous-catégorie et parfois il semble que ce soit la position des blocs qui permet la factorisation.

Cette factorisation n’étant pas essentielle pour l’instant, je me suis rabattu sur une structure avec un LESS par layout et une mixin de même nom, soit gala, incluse dans un namespace spécifique au layout ce qui permet de la coder différent pour chaque layout. Il y a donc beaucoup de duplication de code mais cela permet au moins de paramétrer la largeur des colonnes de chaque layout. De toute façon, notre stratégie de configuration du layout nécessite que nous ayons toujours un fichier CSS par layout.

Le fichier var_layout.less contient plus de paramètres que nécessaire afin d’assurer que chaque changement de configuration du layout puisse permettre d’afficher un layout parfait. C’est un fonctionnement de démo. En fait, le fichier ne devrait contenir que trois paramètres qui devraient s’adapter au layout choisi (exprimé en pourcentage ou en pixels par exemple). Ces paramètres sont :

Nous reviendrons donc sur ce sujet dans une étape ultérieure.

Enfin, j’ai profité de cette étape pour renommer les layouts en gala_nn.css et reporter cette modification dans le fichier inclure/head.html. En outre, j’ai rajouté le numéro du layout gala dans le titre du header.

Fil d’ariane et habillage en LESS

Fil d’ariane

Le fil d’ariane ne fait pas partie des blocs Gala par défaut. Ce bloc a été rajouté dans le body du squelette afin d’être inclus dans l’échafaudage Z. Nous avons défini des styles pour ce bloc dans le fichier css/breadcrumb.css.

Nous allons donc utiliser LESS pour générer les styles du fil d’ariane en créant le fichier de styles less/breadcrumb.less et les variables associées dans less/var_breadcrumb.less. On en profite aussi pour extraire la couleur de fond du fil d’ariane de ces styles pour les transférer dans les styles du thème.
En conséquence, le fil d’ariane ne possède que 4 variables, les marges verticales et horizontales et les paddings verticaux et horizontaux.

Habillage

Le fichier d’habillage actuel du squelette,css/theme.css, est composé d’une séries de styles définissant la couleur des blocs Gala uniquement. On y rajoute donc la couleur du fil d’ariane et on crée ainsi les deux fichiers LESS qui génèreront les styles, à savoir, less/theme.less et les variables associées dans less/var_theme.less.

On garde toujours pour l’instant les quelques styles typo pour le header et le footer afin de conserver le look & feel Gala. Ces styles disparaitront à l’étape suivante quand on positionnera les styles SPIP et les bases éditoriales du squelette.

Conclusion

Suite à cette étape, nous avons extrait un nombre conséquent de paramètres sur lesquels il sera possible de jouer pour agrémenter le squelette assez simplement, en particulier pour la structure des layouts. Pour les layouts, l’optimisation du code sera discutée dans une étape ultérieure.

Comme LESS est un préprocesseur, le squelette utilise toujours des fichiers CSS en inclusion. Il sera donc possible d’inclure d’autres fichiers CSS sans pour autant les passer en LESS. En l’occurrence, le fichier css/form.css n’est pas migré en LESS car d’une part, aucun paramètre n’est identifiable et d’autre part, ces styles seront pour la plupart surchargés par les formulaires SPIP que nous intègreront dans l’étape suivante.