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 :
<div id="sticky-post" class="clearfix span-8 last"></div>
Et en production :
<div id="sticky-post"></div>
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é.
Bonsoir,
La sémantique ne se résume heureusement pas au flux de production ! :-) Je reste convaincu que des bonnes méthodes de travail restent le meilleur moyen d’éviter les erreurs. Il n’en reste pas moins que ton point de vue est très intéressant.
Quand à la sémantique des
span-xx, tu m’a très facilement convaincu et je me range derrière ton point de vue.Pour ce qui est de l’utilisation d’un framework, elle peut effectivement être productive, si comme tu le montre, on s’arrange après mise en place du layout/grille/maquette pour supprimer les classes inutiles et redondantes.
Bref, merci pour ce petit focus sur mon travail, je retourne lire ton site très instructif.
Cordialement, Denis Chevalier
[...] de cet article où je présentais mes doutes quand à la sémantique des framework CSS ? Eh bien Bruno Bichet de CSS4Design vient de me gratifier d’une réponse ma fois fort [...]
Hello,
On voit de suite que tu es très pointilleux. Tu as l’air de maitriser ton sujet. Je n’ai pas encore franchi le pas avec les framework CSS par « peur » de perdre la main sur mon code.
Ton point de vue est intéressant car il remet justement le web designer en position centrale. Utiliser un framework c’est bien, le comprendre c’est mieux. Ta technique est peut-être un peu longue et fastidieuse mais elle a au moins le mérite de permettre de comprendre le fonctionnement de son framework et même de l’optimiser si besoin.
Je suis « presque » convaincu. Bon article!
Au fait ? Tu as terminé ton travail de refonte sur ce blog ou tu es encore en phase de recherche?
Merci beaucoup pour vos retours sur ce billet finalisé sur un Sony Ericsson W595 grâce à Opera mini et à ses 5524 car. disponibles pour l’édition des textes… J’aurai sans doute l’occasion de revenir — encore — sur ce sujet. Stay tuned!
[...] Framework CSS sémantique ? Comment je vois les choses [...]
Je pense que leur utilisation dépends du projet.
Je ne vais pas en utiliser sur un projet personnel sur lequel j’ai le temps de faire une feuille de style css propre, en partant juste d’un reset.css.
Par contre sur des projet professionnels de maquette, ou des projets courts d’intranet ou le design est « secondaire » et ou je n’ai que deux mois de dev, j’apprécie particulièrement les frameworks css et le temps qu’il me font gagner.
Rapidité de prise en main, rapidité de mise en place, rendu correct, c’est un très bon compromis !
Ce que j’aime bien faire c’est utiliser un processeur css php qui fait tout ça pour moi en compressant le tout. On n’a plus à réfléchir et on indique le colonnage dans la css (et non dans le html).
Par exemple :
primary-content { columns: 8; padding: 0 15px;}
Sera interprété pour que #primary-content prenne 8 colonnes avec 15 pixels de padding (le processeur fait l’opération de soustraction tout seul).
J’ai écrit un petit article là-dessus pour ceux que ça intéresse : http://www.lunaweb.fr/coder-en-css-plus-rapidement-plus-intelligemment/
Eh bien, si ça te fais plaisir c’est très bien. Mais ça n’a strictement rien à voir avec la sémantique HTML. Plus généralement, les classes «sémantiques» n’ont rien à voir avec la sémantique HTML (si si), et sont juste une question d’organisation personnelle et/ou collective. Dire du choix d’une classe qu’il n’est pas sémantique est une bêtise. Dire qu’il marche plus ou moins bien dans le workflow d’une équipe est pertinent.
Tu fais d’ailleurs la distinction entre sémantique et workflow dans le paragraphe précédent. Dommage que tu semble alors revenir à l’idée (erronée) de sémantique pour parler du nom des classes. Mais je sur-interprète peut-être?
J’ai vraiment du mal à comprendre la notion de class sémantique. Certes, un nommage cohérent est important pour la maintenabilité du code, mais de la à parler de sémantique il y a un monde.
[...] Framework CSS sémantique ? Comment je vois les choses – [...]
[...] Framework CSS sémantique ? Comment je vois les choses. [...]
[...] Pour rebondir encore un peu sur les questions récurrentes concernant l’utilité d’un framework CSS lors de la phase d’intégration HTML & CSS, je rappelle qu’il est tout à fait possible de travailler avec une grille pour le placement des différents blocs sans pour autant utiliser un framework, comme je le suggère dans Framework CSS sémantique ? Comment je vois les choses. [...]
Salut, j’ai pratiquement terminé le travail avec illustrator, faut juste que je me mette à l’intégration. Quoique avant, j’aimerais en profiter pour étudier le thème Thematic plus en profondeur ;)
Merci encore, je suis pour ma part, je suis content d’avoir découvert ton blog à cette occasion :)
salut,
A la limite, je préfère encore utilser des feuilles de styles carrément dynamiques avec PHP, dans cet esprit : http://www.css4design.com/feuille-de-style-css-dynamique-avec-php :)
Le problème avec les classes et la notion de sémantique, c’est de savoir jusqu’où déplacer le curseur et sur quelle échelle : à priori, je trouve qu’une classe
.text_rouge_12pixels_importantn’est pas très appropriée (je ne parle pas de sémantique) et tout le monde est généralement d’accord pour dire qu’il vaut mieux chercher la signification de ce texte rouge 12 pixels pour trouver un niveau supérieur du style.requiredpar exemple.De même, j’ai la faiblesse de penser que l’on peut basculer vers plus de signification au sein du flux de production (l’équipe, quoi) avec un
.span-xplutôt qu’un.grid_xqui évoque tout de suite une notion de présentation alors que le premier reste assez neutre et peut servir à montrer l’importance accordées aux contenus classés de cette façon : dans le cas d’un travail éditorial en équipe, le.span-xpeut servir à qualifier l’information.Mais comme je le signale à la fin du billet, je n’utilise plus vraiment les frameworks ou du moins, plus la partie grille qui finalement prend beaucoup de place pour placer le contenu et deux colonnes ;))
J’utilise le terme sémantique à dessein car une grande partie des détracteurs des frameworks leur reproche un manque de sémantique, justement. Je précise juste ici ce que j’entends, moi, par sémantique, d’où le « comment je vois les choses » dans le titre du billet.