Blog // Exirel.me

Bootstrap : addendum

Par Florian Strzelecki - 15:10 - 02.06.2012

Tags : #trolldredi, css, lesscss, twitter bootstrap

Bon, j'ai bien ri, peut-être que vous aussi, mais je ne pouvais pas laisser cet article sur la bootstrapite aiguë sans quelques explications supplémentaires.

Dérives

Bootstrap en lui-même n'est pas vraiment un problème. Il y a certaines choses que je n'aime pas du tout (notamment une "légère" perte de contrôle sur l'agencement des classes), mais avec lesquelles je peux vivre. Ou le fait qu'il faille modifier certains fichiers de bootstrap pour modifier des variables d'ajustement (comme le souligne @nautilebleu).

Les dérives peuvent vite venir. J'en parlais un peu en dénonçant ce système de grille, avec ses multiples classes .span* et .row. Pour reprendre la phrase d'un grand philosophe de ces 5 dernières années :

Des .span* et des .row c'est pas grave quand il y en a un ou deux, mais quand il y en a 50 bonjour les problèmes !

Le soucis, c'est qu'il faut passer par l'attribut "class" de vos éléments HTML. Ce qui veut dire que, pour chaque élément HTML que vous avez, vous devez considérer les classes, ce qu'elles font, et en ajouter/retirer au besoin. Donc modifier le code HTML uniquement pour des questions de style.

Ok, là vous pourriez me dire que c'est normal, que, quoi qu'il arrive, soit je modifie le CSS, soit je modifie le HTML, soit les deux, mais que je ne peux pas y couper. Mais je ne suis pas d'accord : vous ne devriez pas avoir à toucher au HTML pour modifier la tête de la bordure de vos éléments, mais seulement à une classe css.

L'intérêt de CSS, c'est de séparer le style de la structure. L'attribut class de mes balises HTML appartiennent à la structure de ma page, et pas au style. Par exemple si un tableau ou un bloc est lié à des données de clients, les classes CSS utilisées devraient avoir un rapport avec ça : "client_facture", "client_achat", ou encore "client_profil". Si j'affiche plusieurs fois ces éléments, je n'ai pas à m'inquiéter d'une longue liste de classes CSS à ajouter à tel ou tel endroit.

Mais si vous utilisez les classes de bootstrap, vous devrez alors ajouter partout où vous en avez besoin une montagne de classes : positionnement, typo, bordure, etc. Ce qui est trop, surtout que vous avez lesscss à côté pour faire des mixins à la place (mais il faut que ce soit compatible avec le fonctionnement de bootstrap, ce qui n'est pas assuré, surtout avec le jeu des imbrications).

Quelques pistes de solutions

Tout n'est pas si sombre. En tout cas, certainement pas aussi sombre que ce que je m'amusais à le décrire dans mon précédent billet (mais nautilebleu l'a fait remarqué, c'était un #trolldredi assumé).

Je pense que le concept de lesscss est une bonne façon de résoudre certains problèmes. Principalement grâce aux mixins. Au lieu de réutiliser les classes de bootstrap pour les assigner à votre code HTML, il serait préférable de les utiliser pour créer vos propres classes css.

Cela demande un travail différent, mais cela permet de conserver la partie style dans la feuille de style, et pas ailleurs. Retour à plus de sémantique, et moins de pollution dans le HTML (et moins de travail si vous avez beaucoup de pages et de vue dans votre application).

Bon, après, reste à tester tout ça, pour voir si ça fonctionne quand même (et cela demande de fouiller dans le coeur de bootstrap, et là, tout de suite, j'ai la flemme).

À noter aussi une idée de @nautilebleu : créer un preprocesseur de css (qui lit le langage less, ou sass ?), en python. Cela nous permettrait, à nous développeur python, de créer ensuite des ponts vers django-compressor et autres techniques. L'idée étant de créer d'autres preprocesseurs avec la même syntaxe, dans différents langages (et assurer une portabilité).

Bref. Il y a du boulot, mais l'idée de structurer le développement des CSS, ce n'est pas une mauvaise idée.