Je ne suis pas d’accord sur un point : identifier un élément comme header ou footer ne sert pas uniquement au CSS, c’est une indication relative à la structure du document, ce qui est le rôle du HTML. D’ailleurs, HTML 5 aura des éléments pour indiquer en-tête et pied de page.

Cordialement

J’ai vu ton article sur LESS : personnellement je m’amuse à combiner frameworks CSS et LESS pour accélérer encore plus la conception.

Les frameworks, c’est une boîte à outil avec des pattern déjà définis. C’est aussi une nouvelle manière de dialoguer entre intégrateur et graphiste

Il fut un temps où on avait séparer la structure de la présentation, maintenant on veut de nouveau les mélanger.

Pour, les feuilles reset ou autres widget c’est sur que c’est pas mal. Mais finalement, on les utilise tous plus ou moins sans le savoir.

Les frameworks CSS sont aujourd'hui davantage des boîtes à outils, des librairies que des outils de RAD c'est certain.

Mais tu vois, <code>#bandeau-haut</code> c'est pas très sémantique vu que tu indiques la position Je te taquine !

Même si comme tu le précises il n’y a pas de forum ou de doc pour comprendre ce qu’a codé un graphiste sans passer par un framework, s’il fait bien son travail, la structure devrait être limpide. Et si ce n’est pas le cas, j’irai lui taper très fort sur le doigts ! Si c’est son métier, il est de son devoir de savoir bien le faire… ou d’y travailler !
Précisions aussi que la doc Blueprint est loin d’être foisonnante et que passer par le .css reste souvent le plus efficace pour en comprendre le fonctionnement… C’est d’ailleurs ce qu’ils suggèrent !

Firebug et l’inspecteur HTML c’est bien, (et même hyper pratique !) mais ce n’est pas du tout dans ma culture d’informaticien de devoir passer par le rendu pour comprendre le code. Quand j’ouvre une page de code et que j’y trouve un je comprends que j’y verrai le menu. Je peux même par la suite rechercher « menu » dans ma page pour retrouver cet élément. Laissons tomber ce fonctionnement avec des « span-* » !

Enfin le mot « framework » CSS est quand même un bien grand mot, je trouve. Je réutilise pour ma part les même CSS entre divers projets (layout.css, balises.css, …) et je retrouve mes définitions directement utilisables : #bandeau-haut, #menu, .ligne-active, … Pour les « frameworks » CSS comme blueprint, la réutilisation du code au contraire est proche de zéro car tu n’as que des classes extrêmement génériques.
Personnelement je verrais plus un framework CSS comme un créateur de classes à partir d’autres classes plus génériques… ce que CSS2 ne permets pas.

Je suis sûr que le débat peut tenir des heures, et tant mieux, il en faut pour tous les goûts, mais je reste complètement de l’avis de Henry : mettre des span-8 c’est un peu comme mettre un et donc je ne l’accepterai pas comme tel dès que je dépasse le stade du site « jetable » qui doit être codé rapidement.

L’aspect non-sémantique est une bonne raison de pester contre les frameworks mais davantage dans leur implémentation que leur utilité (faut-il encore la démontrer ?). C’est pour ça que certains sont bien fichus mais uniquement parce qu’ils m’imposent des ID CSS, je ne les utiliserai pas.

Maintenant faut pas se leurrer : l’utilisation absolue d’un framework n’est pas à appliquer systématiquement. C’est bien leur avantage d’être modulaire : on ne veut que la grille OK ; on ne veut que le reset+typographie OK. Ça reste quand même très souple … même plus souple que le premier framework JavaScript venu.

C’est marrant mais les CSS c’est le dernier bastion de l’industrialisation : on veut bien automatiser tout le reste mais pas ça.
Peut-être parce que c’est actuellement un des besoins les plus mal cadrés et parce qu’on cèdera plus volontiers du terrain face aux clients.

@Mathieu non tu as bien compris le principe des CSS mais on met toujours un peu de non-sémantique sans s’en rendre compte. #header ou #footer par exemple ne sont pas sémantiques puisqu’ils indiquent une position dans la page.
Sans générateur, je ne pense pas qu’on puisse facilement déclarer des largeurs de colonnes sans faire comme YUI et ses .yui-ge & cie.
Je pense qu’on peut être exigeant sans être trop intégriste non plus.

Maintenant, je suis convaincu que les frameworks CSS ne sont plus une bonne solution dès que tu peux avoir une équipe dédiée à l’intégration graphique. Un bon intégrateur t’obtiendra les même résultats en un temps similaire, sans utiliser de framework. Les graphistes auront aussi de ce fait une liberté bien plus grande que de s’aligner sur une grille !

Enfin quand tu réalises des projets susceptibles de passer de main en main (comme un projet opensource, ou même un projet professionnel avec de grosses équipes), l’aspect non sémantique c’est à peu près aussi horrible que de reprendre du code avec des variables qui s’appellent ‘$i’ et des formules du genre ‘$mc = $jm*$v/(calcule($brg, $cmt, 1))’. En effet, si tu vois un ’span-8′ il faut (grosso modo) que tu regardes tous les éléments à la même profondeur et ayant le même parent pour comprendre un peu sa disposition… c’est un peu comme remonter aux définitions des variables : ça prend du temps, ça énerve et ça peut facilement être évité.

Donc je continue à dire « oui… mais »

Comme je l’indique dans mes slides, il y a aussi des raisons de ne pas les utiliser : c’est pas le Saint-Graal et faut surtout pas s’imaginer qu’avec, le monde sera beau et rose. Quand on utilise un CMS ou autre, on ne peut plus faire ce qu’on veut et des fois on galère pour une chose simple.
Blueprint permet de s’affranchir de la très grande majorité des problèmes puisqu’on peut générer une grille de manière sémantique en indiquant que tel ou tel ID utiliseront X ou Y colonnes de large. Tu as un outil intégré (le compressor) mais aussi Blueprint Grid CSS Generator, plus limité certes.

@pixenjoy content que t’aies apprécié C’est mieux d’en parler de vive voix que sur un article où on est plus rétif à considérer un avis.
C’est clair que si un graphiste bosse avec une grille, c’est indéniablement plus facile à intégrer.

@wikine Ouaip, YUI CSS est un bon outil. Mon seul reproche c’est une sémantique qui rend leur utilisation difficile sans cheat sheet sous les yeux.

@djib & @henri alors oui pour la sémantique mais je suis prêt à faire ce sacrifice là du moment que ça reste compréhensible. Je ne jouerai pas les intégristes à ce point quand j’ai un ID qui s’appelle #header ou #footer. Cf. ce que j’ai dis plus haut pour la config sémantique de Blueprint.