Un framework CSS ne dispense pas de réfléchir !

Beaucoup de questions posées au sujet de KNACSS me laissent penser que cet outil est parfois mal employé. Je préfère en rajouter une couche…

Un Framework CSS fournit un nommage et des classes génériques réutilisables, une façon d’accélérer son workflow et de faciliter la maintenance de ses projets.

Mais rien n’est magique : tout Framework, quel qu’il soit – et KNACSS en fait partie -, doit s’articuler sur une base saine : un code HTML propre et doté de sens, ainsi qu’une bonne connaissance initiale en CSS.

Tout ne peut pas être automatisé, vous devez personnaliser l’outil à votre projet. Il est indispensable de ne pas se fier uniquement à un Framework.

##Cinq règles à suivre si vous utilisez un Framework CSS :

  1. Commencez par une base HTML sémantique. L’un des pièges d’un Framework est de ne penser qu’aux noms de classe et d’en oublier les bonnes balises.

    Ex. Un <div class="submit"> est une aberration : si vous voulez un .submit, c’est que votre élément est un ou un.

  2. Évitez de sur-classer vos éléments.

    Ex. Si vous avez 20 images au comportement identique dans la page, ne les affublez pas de classes visuelles multiples telles que img class="mod clearfix left inbl w200p pas mb1 large-mb2 small-mbn" mais optez plutôt pour une classe personnalisée : img class="media".

  3. Maîtrisez votre outil. On a souvent tendance à se jeter sur un Framework… et à l’utiliser n’importe comment.

    Ex. L’extrait de classe décrit au point précédent (img class="mod clearfix left inbl w200p pas mb1 large-mb2 small-mbn") aurait dû vous choquer car plusieurs classes sont tout bonnement inutiles : un .modcontient les flottants donc .clearfix est inutile, de même que .left (float) écrase forcément .inbl (inline-block). Ceci, vous ne pouvez le savoir que si vous connaissez bien votre framework… et CSS.

  4. N’abusez pas des classes “non sémantiques”. Deux mondes doivent pouvoir cohabiter : l’intégration “classique” et les méthodes “orientées objet” (OOCSS) employant des classes “visuelles”. Ne soyez pas partisan du Tout ou Rien.

    Si votre élément est clairement identifié comme une sidebar et s’il n’y en a pas 10 sur la page, la classe .sidebar sera parfaite !

    Utiliser un framework, ce n’est surtout pas utiliser uniquement des classes visuelles : c’est d’abord donner du sens aux éléments principaux, et choisir des classes “visuelles” réutilisables seulement là où c’est nécessaire.

    En ce qui me concerne, j’identifie bien évidemment les éléments à l’aide de classes porteuses de sens… sauf pour les éléments répétitifs (patterns).

  5. Appropriez-vous votre Framework. Ces outils sont généralistes et ne peuvent pas couvrir tous les besoins à la perfection… en tout cas pas sans avoir été adaptés à ses propres besoins.
    Bref, modifiez, ajoutez, corrigez votre Framework en fonction de votre projet.

##Un exemple concret ?

no

L’une des principales critiques faites aux frameworks est qu’il est possible de générer ce genre de code, où l’on retrouve des répétitions abusives de classes purement visuelles.

L’illustration ci-dessus est l’exemple parfait à ne pas reproduire en production.

En effet, ce n’est pas parce qu’un framework permet d’obtenir ce genre de lourdeurs impossibles à maintenir qu’on n’est obligé de procéder ainsi.

Dans un cas concret comme celui-ci, la meilleure solution est de traiter chacun des deux blocs de liste <ul> comme un module qui peut devenir totalement autonome et nommé .modal-content-list.

Les items de ce module pourront alors être traités indifféremment comme des .modal-content-list &gt; li, soit comme des .modal-content-list-item.

Ainsi, plutôt que d’affubler ces éléments de multitudes de classes, traitez-les et stylez-les individuellement en fonction de leur nom.

Rappelez-vous simplement que tout n’est pas automatisable, et c’est tant mieux !