Construire son framework CSS

Tout d’abord, qu’est-ce qu’un framework CSS ? En programmation informatique, un framework est un kit de composants logiciels structurels, qui définissent les fondations ainsi que les grandes lignes de l’organisation de tout ou partie d’un logiciel (architecture). Les frameworks sont au code ce que les préfabriqués sont au BTP. En développement front, un « framework CSS » est un lot de feuilles de styles prêtes à l’emploi, qui facilitent le montage des pages web. Les plus connus sont Blueprint, 960 Grid System, Bootstrap…

Adopter un framework ?

Le débat fait rage ces dernières années, pour ou contre l’adoption d’un framework CSS. D’un côté le design from scratch est défendu par des développeurs, souvent indépendants, certains se revendiquant artisans, qui souhaitent légitimement garder le contrôle sur la production d’un code qu’ils connaissent, puisque le leur… De l’autre, l’adoption d’un framework est défendue par celleux qui, travaillant à plusieurs sur du code partagé, qu’il faut maintenir dans le temps, préfèrent homogénéiser les pratiques pour réduire les conflits de code, et par celleux qui souhaitent industrialiser pour produire plus vite, monter rapidement des interfaces, dépoter du site standardisé…

Aucune de ces deux approches ne m’agrée. C’est que la question est mal posée. C’est oublier ce que signifie framework : ce n’est qu’un cadre de travail. C’est qu’en pratique, aucun développeur ne part d’une page blanche : chacun a stocké, au fil du temps, des bouts de CSS qui lui servent de base. C’est sa trousse à outils, son cadre de travail, bref déjà un « framework ». Pourquoi utiliser d’autres bouts de code, d’autres frameworks que le sien ? Parce qu’il serait dommage de ne pas profiter d’autres astuces, nomenclatures, conventions… sous peine de réinventer la roue chacun dans son coin. Réutiliser du code, sien ou tierce, est ce que nous faisons déjà tous et toutes.

Ensuite, il ne faut pas rêver : aucun framework, si génial soit-il, ne comblera tous vos besoins. Il faudra nécessairement compléter voire adapter. Le framework qui s’impose en ce moment, Bootstrap, est bien pratique, pour ses formulaires et boutons par exemple, mais sa grille reste plus laborieuse à utiliser, notamment par des débutant·e·s, que 960 Grid System ou Layout Gala, et son traitement de la typo est assez minable… Je continue de lui préférer la rigueur typo de Blueprint.

Chaque framework ayant ses atouts et ses faiblesses, pourquoi ne pas prendre le meilleur de chacun, plutôt que de s’en tenir à un seul, comme s’il fallait se choisir un seul maître ?

Quel framework… pour qui ?

Dans ce débat a priori technique, il ne faut pas oublier la composante humaine, qui est sans doute la plus déterminante ici. C’est-à-dire celleux qui interviennent sur un projet, celleux qui vont toucher au code en cours, mais aussi après, avec des niveaux de maitrise parfois sensiblement différents.

Ainsi on ne mettra pas Bootstrap — ce framework qui se présente lui-même by nerds, for nerds, c’est-à-dire bien velu, fait par des développeurs pour des développeurs — entre les mains de débutants, de webmestres qui touchent leur CSS une fois l’an, parce qu’il réclame un trop haut niveau de maitrise, non seulement du CSS, mais aussi de LESS, de la notion de variables, etc. toutes choses kiffantes mais qui ne sont pas acquises au commun des mortels, pardon d’en rappeler l’existence. Dans tel contexte, sans doute faudra-t-il préférer un micro-framework, tel que KNACSS qui tient en une seule feuille CSS, tout de suite moins effrayante, et immédiatement utilisable. Son auteur, Raphaël Goetter, rappelle que CSS, ce n’est pas que pour des robots et se préoccupe de la réalité du code partagé (entre autres) par des collègues (intégrateur novices, experts, développeurs, graphistes), bref, des humains.

Construire son framework !

Parce qu’aucun ne répond entièrement aux besoins, parce qu’il faut compléter, adapter à chaque projet, aux humains, parce que ré-utiliser du code pré-existant, le ré-assembler, est ce que nous faisons déjà, la réalité est moins l’adoption que la construction. Mais comment construire son framework de façon perenne, sans s’embarquer dans une énième usine à gaz ?

1. Adopter une méthode de découpe

Plutôt que d’adopter un framework tel quel, je propose d’adopter une méthode de découpage de ceux-ci, plus précisément une nomenclature transverse, qui laissera la liberté de changer telle ou telle brique de code ultérieurement. Tel est le principe de la méthode Daisy.

2. Choisir le meilleur de chacun

Ne reste plus qu’à choisir le meilleur des ressources CSS existantes, c’est-à-dire les plus appropriées au projet et à ses humains, pour en construire la base CSS. Par exemple, sur l’un des derniers projets, où le framework devait servir à fabriquer quelques centaines de sites, maintenus non par un dev front aguerri mais par quelques webmestres bidouilleurs, voici ce qui a été retenu :

1. reset : le reset de Meyer
2. typo : la typo de Blueprint
3. forms : les formulaires de Bootstrap
4. grid : 960 Grid System
5. layout : un de ceux de Layout Gala, puis finalement non
6. blocks : et les modules d’ooCSS

Cette organisation permet de changer d’avis sans trop de casse, c’est-à-dire sans devoir tout remettre en question. C’est ainsi que nous avons abandonné la grille de Bootstrap en cours de route, parce que trop s’y cassaient les dents, pour celle de 960 Grid System. Il a suffit de remplacer le code CSS du fichier grid.css et, bien entendu, les class correspondantes dans les fichiers HTML. Certes un peu laborieux, mais cela s’est fait sans endommager le reste.

Attention, il est important, quand on utilise ainsi des bouts de code distribués, par ailleurs documentés, de les utiliser tels quels, sans les modifier. Si elles s’avèrent nécessaires, les personnalisations se font ultérieurement, dans un fichier à part, par surcharge CSS. Pourquoi ? Pour bénéficier de la documentation, mais aussi des conventions de nommage qui peuvent être par ailleurs acquises par les intervenants.

3. Sans oublier les pages HTML de démo

Un framework n’est pas qu’un lot de fichiers CSS. Car un fichier CSS n’est rien sans le HTML auquel il est sensé s’appliquer. À chaque fichier CSS significatif (c’est-à-dire sauf le reset) est donc associé une page HTML homonyme, qui sert à voir comment s’appliquent les styles.

Cela constitue un styleguide, ou « guide de styles », à destination de tous celleux, présents ou à venir, qui vont utiliser ce cadre de travail. C’est ainsi que le nouveau venu sur le projet, junior, n’a pas eu trop de difficulté à s’approprier ce code. Et c’est indolore pour les développeurs back, peu à l’aise avec les CSS, qui n’ont plus qu’à appliquer ce mode d’emploi.

4. Personnaliser cette base

Cette base ainsi construite, en pièces détachées, peut être consolidée, sur le site en ligne, en un seul fichier, tout simplement appelé base.css, auquel on n’apporte ensuite pas de modification.

Les personnalisations — les polices de caractères, les couleurs et autres caractéristiques du site — sont apportées à part, dans un ou plusieurs fichiers séparés, qui sont appelés à la suite.