Cet article fait partie de la série sur les ateliers Paris Web 2013.
Raphaël Goetter (@goetter) et Nicolas Hoffmann (@Nico3333fr) ont chacun créé leur propre micro-frameworks CSS : KNACSS et RÖCSSTI.
L’atelier était pour eux l’occasion de revenir sur la démarche de création d’un framework CSS, et de mettre en commun et partager autour des retours d’expérience d’utilisation.
Un rapide tour des frameworks existants permet de faire la distinction entre micro-frameworks (KNACSS, RÖCSSTI) et « usines » (Bootstrap, Foundation…) : les premiers sont plutôt une base neutre, rapide mais modulaire, pour le travail d’intégration, tandis que les seconds essaient de couvrir de manière quasi-exhaustive les besoins possibles en fournissant une palette plus approfondie d’éléments, avec parfois en plus des thèmes visuels déjà prêts.
La question duquel utiliser, et comment, dépend alors bien sûr des besoins du projet : si la surcouche de design envisagée est par exemple très importante, il serait contre-productif d’alourdir les choses en devant surcharger un thème visuel déjà inclu.
Après avoir rapidement abordé les raisons de créer et/ou utiliser un framework (se faciliter la vie et gagner du temps en ne réinventant pas la roue à chaque fois), c’est ensuite l’occasion d’échanger sur ce qu’un framework devrait contenir, offrir en bonus, ou devrait absolument éviter… selon les présentateurs.
Les retours d’expérience des participants mettent alors en avant des différences d’attentes, toujours selon les besoins et projets rencontrés.
La gestion des formulaires et des styles d’impression, indispensable ou non ? Ne pas utiliser d’!important, est-ce-si important que ca ? Peut-on déterminer de manière absolue quels sont les « éléments qui servent rarement » et n’ont pas leur place dans le framework ?
On évoque alors les raisons qui les ont chacun poussé à rendre leur framework public : d’un côté, « la philosophie alsacréations » de mettre à disposition du plus grand nombre les compétences disponibles, et de l’autre, plutôt un encouragement de l’entourage à diffuser, car cela dépassait la portée du simple intérêt personnel.
Chaque framework prend donc son temps pour grandir et évoluer, au fil des apports de la communauté et de l’évolution constante du métier.
Viennent ensuite les « sujets sensibles », les grilles tout d’abord : fonctionnement fixe ou fluide ? Faut-il pouvoir les imbriquer ? Plutôt définie sur le conteneur ou sur les éléments enfants ? Autant de questions qui n’attendent pas une seule réponse, mais des prises de décisions selon les besoins et le contexte.
On relance également le débat de la « sémantique » : peut-on garder du sens visuel lorsque les éléments s’adaptent en responsive ? Parle-t-on de la sémantique de ce que fait l’élément, ou plutôt de donner du sens pour les autres intégrateurs qui travailleraient sur le projet ?
Autre sujet prêtant à débat : quid de l’utilisation des préprocesseurs ? Les partisans (dont nous sommes !) mettent en avant les avantages : variables, extends, imports pour ne garder que les parties du framework que l’on va effectivement utiliser…
Enfin, bien qu’on trouve de « mauvaises utilisations » des frameworks, on s’accorde pour dire qu’utiliser un framework est riche d’apprentissages : respecter ou mettre en place des conventions de nommage, réfléchir en éléments modulaires plutôt qu’en pages… La documentation joue alors un rôle important pour comprendre les mécanismes mis en oeuvre par les créateurs.
Vous pouvez consulter en ligne les slides de cet atelier.
Tout le monde aura finalement retenu cette phrase de Raphaël, qui servira de résumé (de cet atelier, mais aussi de Paris Web et du processus d’intégration en général) : « ça dépend » (du contexte, des besoins, d’où on met le curseur entre rapidité d’exécution et maintenabilité…).
A lire aussi :
Première participation aux ateliers Paris Web
Test unitaire ? Mock ? TDD ? Kezako ? (En finir avec les régressions)