Framework CSS sémantique ? Comment je vois les choses

Je reviens vers vous sur la question des frameworks CSS suite à la lecture de A Reflexion About Semantic Grids qui défend grosso modo le point de vue selon lequel les frameworks ne sont pas sémantiques et incitent à marcher sur la tête en bousculant le flux de production web.

A première vue, les classes ajoutées au code HTML par les déclarations présentes dans les bibliothèques CSS sont essentiellement destinées à la présentation. Un peu comme si l’on mettait une classe .rouge pour afficher en rouge ce qui est important dans le texte, alors que tout le monde sait que .red, étant plus court, est bien plus approprié ^_^v (je suppose ici que les professionnels du web seront sensibles à l’ironie ; je ne suis pas inquiet pour les autres !).

Ensuite, à cause des frameworks CSS, l’intégrateur serait obligé de commencer par la feuille de style au lieu de baliser correctement son contenu avec du HTML bon CHIC (Code Html Intrinsèquement Classe) bon genre.

Vous avez dit web sémantique ou flux de production web ?

Je ne suis pas vraiment convaincu par ces arguments car la sémantique ne se réduit pas à la place des opérations à accomplir dans le flux de production web : à partir du moment où l’on connait le pas de la grille, il n’y a aucune raison de ne pas générer le fichier grid.css qui va bien. D’autant plus que cette grille ne devrait avoir aucune influence sur la qualité du code HTML à venir, si justement, l’intégrateur ou le webdesigner a pris soin de séparer le fond de la forme en amont.

Mais surtout, à part quelques frameworks qui nécessitent jusqu’à trois classes — voire plus — pour placer un bloc (ce qui commence à manquer de factorisation), la suite des .span-x peut se comprendre comme l’importance accordées à chaque bloc : du moins important (.span-1) au plus important (.span-24), à l’image de la presse écrite où un article surmonté d’un titre en 8 colonnes à Une mérite plus d’attention qu’un entrefilet sur 2 colonnes.

C’est dans cet esprit que je préfère un .span-x à un .grid-x, d’autant plus qu’il existe déjà un élément span en HTML.

Est-ce une raison pour justifier l’utilisation d’un framework CSS ?

J’aime bien tester rapidement différentes déclinaisons d’une charte graphique avec les frameworks. En effet, dès que le fichier grid.css (ou layout.css, maquette.css, etc.) est en place, on peut déplacer les blocs de contenus très rapidement : l’Édito sur 6 ou 8 colonnes ? Le Sticky Post, avec une marge à gauche ou à droite ? etc.

Quand les choix sont validés, je refais la partie layout de mon fichier styles.css avec les éléments utilisés réellement tout en gardant grid.css sous le co(u)de prêt à servir avec une règle @import entre commentaires.

Par exemple, pour tester ma grille, j’ai tendance à utiliser :

Et en production :

Avec :

#sticky-post {
width: 310px;
float: left;
margin-right: 0;
overflow: hidden; /* avec #sticky-post { zoom: 1 } dans le fichier ie.css */
}

Et ainsi de suite avec tous les éléments de la page. C’est un peu fastidieux, mais au final — et pour peu que vous réunissiez toutes vos CSS dans un fichier unique bien commenté — votre code HTML et votre feuille de style CSS y gagneront en lisibilité et surtout en légèreté.