Les frameworks CSS ont fait couler beaucoup de pixels : d’un côté, ils proposent une méthode à l’épreuve des balles pour placer les blocs sur sur la page en tenant compte des contraintes cross-browser ; de l’autre, ils ajoutent des classes CSS superflues dans le code HTML pour la présentation des contenus, ce qui n’est pas jugé «sémantique» par les farouches défenseurs d’une séparation entre le fond et la forme. Voilà en gros l’avantage principal et l’inconvénient majeur qu’on peut dégager si on met de côté le faux problème du poids de ces frameworks. Après avoir donné mon point de vue sur cette question de «sémantique» j’expliquerais comment l’ajout de classes liées à la présentation dans le HTML peut s’avérer très pratique à l’heure du web «sur-mesure».
Comment ça marche, un framework CSS ?
Le positionnement des blocs avec un framework CSS s’effectue grosso modo en attribuant une classe CSS pour spécifier les propriétés `width` et `margin` aux blocs avec une ou plusieurs techniques pour rétablir le flux HTML après les éléments possédant la propriété `float`.
Dans une grille en 16 colonnes, pour placer une image sur 4 colonnes et du texte sur les 12 restantes, on pourra utiliser le marquage HTML suivant (je vous fais grâce des CSS, le code HTML est assez explicite) :
<div id="header" class="grid_16 clear"> <div class="grid_4"><img src="/img/logo.png" /></div> <div class="grid_12 last">Mon texte sur 12 colonnes</div> </div>
Pour beaucoup, les classes .col_16 et last (voire même .clear) sont une intrusion, que dis-je, une déclaration de guerre de la forme contre le fond. Pour tout dire, je suis assez partagé moi-même sur le sujet, mais je m’accroche… J’utilise souvent la partie «grille» des frameworks pour mettre en place la structure des pages car j’ai déjà l’habitude de concevoir le design d’un site avec un découpage en colonnes.
Attention, pas forcément du tout fait en 950px ou 960px mais en déterminant le «pas» de la grille selon mes besoins. Je laisse ensuite les fastidieux calculs à un générateur de grille, qu’il s’agisse de boks pour Blueprint ou encore de 960 Layout System pour 960.gs.
Un peu (ou pas) de sémantique
Les classes .span-4 ou .grid_4 ne sont pas sémantiques dans le sens où — pour certains — elles véhiculent une notion d’apparence et non pas d’utilité, de sens. Ainsi, une classe .warning est préférable à une classe .rouge même si la couleur de .warning est rouge ; si on change d’avis, on aura l’air fin avec notre classe .rouge affichant du texte orange. L’idée, c’est d’être à la fois très précis et suffisamment générique pour s’adapter à toutes les situations.
Pour revenir aux classes spécifiant la largeur des colonnes, j’ai toujours pensé qu’elles apportaient du sens, un peu à l’image de la presse quotidienne où l’on met un titre sur 8 colonnes, signifiant ainsi son importance par rapport aux autres contenus (à supposer que la maquette comporte un maximum de 8 colonnes).
Le côté sémantique de la chose est surtout à mettre en regard des contenus à maquetter : s’ils n’ont pas de sens en eux-mêmes, toute la sémantique du monde n’y pourra rien changer 😀
Pour finir avec cette question de sémantique, il reste la possibilité de renommer les classes .span-x ou .grid_x. En fonction de votre projet, vous pourrez utiliser des termes plus en accord avec vos contenus comme .a-la-une pour .span-16, .breves pour .span-4 ou encore .entrefilet pour .span-2, etc. On peut donc considérer que des contenus auxquels on applique un .span-16 sont plus importants que ceux auxquels ont attribut la classe .span-4 et ainsi de suite.
Comme j’ai déjà eu l’occasion de le dire dans Framework CSS sémantique ? Comment je vois les choses (et au risque de me répéter) :
[…] 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.
Les avantages des frameworks CSS
Standardiser les méthodes de travail
Quand plusieurs personnes interviennent sur le code HTML pour placer ou déplacer des éléments (ex. supprimer ou ajouter une sidebar, un bloc de contenu, etc.) il vaut mieux avoir un jeu de classes CSS (issus d’un framework ou non, d’ailleurs) pour éviter que chaque intervenant bidouille le fichier CSS avec sa «méthode» : certains sont adeptes des `position: absolute`, d’autres raffolent des `float: left`, d’autres des `table`, etc. Avec des classes standardisées comme span-x, last et les clearfix qui vont avec, tout devient plus simple et cohérent.
Des maquettes dynamiques côté serveur ou client grâce aux grilles
Autre argument qui milite en faveur de la mise en place d’une grille avec un framework, c’est qu’en travaillant de cette manière, il devient possible de modifier dynamiquement la mise en page côté serveur avec PHP ou côté client avec Javascript.
Pour distribuer votre contenu sur 4 colonnes au lieu de 8, il suffira de modifier tout ou partie du nom de la classe utilisée (le «4» de col_4 par «8», par exemple) sans être obligé d’intervenir sur la feuille de style ou d’en charger une autre à la volée.
Frameworks PHP, Javascript et pourquoi pas CSS ?
Les critiques concernant les frameworks CSS sont souvent les mêmes que celles qui ont été faites contre les frameworks PHP ou Javascript avant que leur utilisation se généralise. Pour illustrer mon propos, voici un extrait de l’intervention de Didier Galland sur WebDevFr à propos de l’industrialisation de l’intégration web :
On a tenu exactement le même discours à propos de PHP, puis à propos de javascript. Les frameworks dans ces deux domaines ont largement prouvé qu’ils permettaient des améliorations. Je ne vois pas pourquoi l’intégration (css/html + javascript) ne pourrait pas bénéficier des mêmes améliorations. On a le droit d’utiliser son framework personnel dans son coin, mais pour le bien de mon agence, je ne peux pas bloquer mes futures évolutions (en personne ou en techniques) à cause de cette attitude, j’aurais donc forcément tendance à privilégier un professionnel au courant de ces techniques dans mes recrutements ou mes contracteurs freelances.
Aller au bout de la logique du reset CSS
Tout le monde connait le reset CSS d’Eric Meyer que l’on trouve dans de nombreux framework. Quand on y réfléchit cinq minutes, la suite logique de ce reset, c’est le frameworks. Il faut bien voir que la plupart d’entre eux ne sont pas spécialement très lourds et quand on fait le compte des déclarations redondantes qui se trouvent dans une feuille de style un peu touffue (parce qu’évidement, si votre projet tient en 20 lignes de CSS, c’est peut-être pas la peine de se poser la question), on se rend compte que les frameworks ne sont pas si gourmands.
Remplacer les styles par défaut des navigateurs
J’ai toujours trouvé que les styles par défaut appliqués par les navigateurs manquait d’originalité et de peps. Il suffit de mettre un soupçon de Boilerplate ou de Typogridfy pour que de très banal, la mise en page par défaut prenne un coup de jeune et de modernité !
Comment déterminer le «pas de la grille»
Un argument récurrent qui va à l’encontre de l’utilisation des grilles concerne la partie conception graphique. Les grilles entraveraient la créativité. Pourquoi pas. Mais je mets au défi quiconque de proposer un design de site web qui ne rentrerait pas dans une grille. Une grille n’est pas forcément synonyme de 12, 16 ou 24 colonnes. Il peut s’agir de 2, 4, 6 ou 8 colonnes et pourquoi pas d’un nombre impair de colonnes comme 1 colonne (un peu le degré zéro de la grille, mais bon…), 3 ou 5 colonnes pour bénéficier d’une asymétrie créative ? Tout est possible.
Pour aller au plus simple, si l’on veut un site avec un bloc de contenu et une barre latérale, on pourra diviser la page en 3 parties pour obtenir les ratios 2/3 pour le contenu principal et 1/3 pour la sidebar ou en 4 parties, soit 3/4 pour le contenu principal et 1/4 pour la barre latérale. On pourra se baser sur les proportions 1/3 ou 1/4 pour la largeur des images accompagnant les textes.
Ensuite, rien n’empêche de diviser chaque colonne en plusieurs parties pour granulariser l’information selon les besoins : affichage de miniatures, etc. Celà permet d’obtenir une mise en page très simple tout en bénéficiant d’une système de grille souple et efficace.
Quelques liens à propos des frameworks et des reset CSS
- 30 frameworks CSS — Mettez une grille (ou pas) dans votre site web
- Frameworks CSS + Reset CSS : design from scratch
- Quelques notes sur les grilles de mise en page
- Grid Design — Quelques notes sur l’intérêt des grilles de mise en page
- Framework CSS sémantique ? Comment je vois les choses
- Framework CSS — mettez vos grilles au pas !
- Nombre d’or, suite de Fibonacci et autres grilles de mise en page pour le design web
- Styles CSS par défaut : après Reset Reloaded, Eric Meyer fait encore risette avec Resetting Again
- 5 Reset CSS à la loupe pour une remise à zéro des valeurs par défaut des navigateurs
Pas de conclusion hâtive !
Je pense que j’aurais l’occasion de revenir sur ces questions (oui encore) notamment sur la partie grille et créativité qui semble passionner beaucoup de monde à juste titre. N’hésitez pas à partager vos expériences en la matière. A bientôt !
Complètement d’accord avec toi.
Pour ceux qui travaillent en collaboration sur le même projet, ils deviennent indispensables en permettant d’uniformiser la structure générale.
Après, comme tu le dis, rien n’empêche de garder l’esprit « grille » sans utiliser un framework complet.
oui aux frameworks css !
comme tu le dis, le poids n’est pas vraiment un problème à prendre en compte, il n’y a en général que quelques ko minifiés (avant même gzip), qui sur des sites « modernes » passent inaperçus : 50K de HTML, 200K de JS, 50k de css, 200K d’images ne sont plus des chiffres délirants.
Et en période de conception on peut générer assez facilement des gabarits HTML pour changer rapidement de layout.
pour ma part je signale l’excellent YUI css reset + grids + fonts
le reset permet effectivement d’avoir des styles de base uniformes sur tous les browsers, fonts permet d’avoir les mêmes tailles relatives (em, %) de police partout, et enfin grids permet avec un peu de markup de construire un layout complexe, indépendant de l’ordre dans la source. Et il y a un outil pour faire ça rapidement : http://developer.yahoo.com/yui/grids/builder/
J’étais un fan du framework YUI mais les développeurs de Yahoo! ne l’on pas fait évoluer pour le HTML5.
Donc aujourd’hui j’utilise mon propre framework composé du reset de « html5doctor.com » et Eric Mayer et de la base inspirée du YUI CSS Fundation. Ma composition personnelle est mon « grid » composé à partir de la nomenclature du HTML5 (
#doc, #header, #footer, #core, #sidebar, .header, .footer, .section, .nav, .article
).En bref, YUI est excellent pour du XHTML uniquement. Et le « YUI CSS Grid » demande un long apprentissage (learning curve) avec son jargon de class étourdissant.