J’ai eu peur il y a 2 semaines en arrivant à Paris-Web 2008 : en discutant avec plusieurs personnes, il se trouve que peu d’entre elles connaissaient les frameworks CSS. Je craignais de n’attirer personne avec ce sujet lors des ateliers du samedi.
Les frameworks CSS ont été mentionnés la première fois dans la conférence Working in the Now (visualiser la présentation). Au final, on n’était pas loin de faire salle comble avec plus d’une vingtaine de participants à vue de nez.
Une petite scéance de rattrapage s’impose 
Pourquoi avoir choisi ce sujet ?
J’ai lu un article sur l’importance du rythme vertical l’an dernier sur Biologeek et ça m’a sensibilisé au fait qu’on pouvait rendre la lecture d’un site tout simplement en rendant prédictible la position du texte.
Entre temps j’ai également lu l’excellent Transcender CSS d’Andy Clarke. J’y ai été sublimé par des présentations de sites totalement en grille.
Depuis je suis devenu fan de Blueprint CSS (je crois que ça s’est remarqué lors de mon intervention ;-)). J’ai commencé à l’utiliser sur des projets personnels puis dans un cadre professionnel. J’utilisais déjà symfony comme framework PHP et jQuery comme framework JavaScript alors pourquoi pas Blueprint ?
Comme le suggérait très justement Christian Heilmann dans sa présentation, l’utilisation d’outils déjà existants est nécessaire pour réduire les coûts de production. C’était déjà un bon alibi mais je les apprécie aussi parce qu’on gagne un temps fou ! On se concentre sur le code métier, pas le reste.
La présentation
Je n’en dis pas plus, je vous laisse lire la présentation. Ayez toutefois en tête qu’en vrai elle dure facilement 1h.
Ce qu’il faut en retenir
J’ai rencontré 2 types de réactions lorsque j’ai parlé des frameworks : les enthousiastes et les réfractaires.
Je ne reviens pas sur les enthousiastes : il suffit de lire ma présentation. Les atouts les ont clairement séduit.
Je m’intéresserai plutôt aux réfractaires. Assez paradoxalement, ce n’est pas dans la salle que je les ai eu mais en dehors. Les principaux arguments étaient :
- ça rajoute des kilo-octets superflus
- on perd le contrôle de notre code
- j’utilise déjà le mini-framework d’un collègue ou qui existait dans mon entreprise avant que j’arrive
Ces arguments sont tout à fait acceptables … mais ça dépend dans quel contexte.
Exemple de mise en forme en grille
Les sites à la recherche de performances exceptionnelles, ceux pour qui un Ko supprimé économise plusieurs Go de bande-passante par jour … oui ceux-là ont un grand intérêt à réfléchir à l’adoption d’un framework, aussi compressé qu’il soit.
Je ne me fais pas de soucis pour eux : en général ils ont leur propre framework, totalement adapté à leur besoin. Cependant ça n’empêche pas d’aller prendre des idées ailleurs et de découvrir de nouveaux concepts. Puis de les intégrer.
Lorsqu’on adopte un outil de développement rapide (RAD), la conception ne se fait plus par rapport à nos habitudes mais par rapport à des principes établis. On ne fait plus forcément comme on veut mais les meilleurs frameworks disposent de fonctionnalités répondant à cette problématique. Le compressor de Blueprint en est un parfait exemple.
Il permet de construire une version de Blueprint adaptée à son besoin, inclut des feuilles de notre choix et compresse le tout en un seul fichier prêt à la mise en production.
Maintenant l’avantage d’un framework c’est qu’une communauté ou un groupe de personnes compétentes en ont la gestion. Ces mainteneurs produisent une documentation, des spécifications et un code suffisamment compréhensible à lire. Ce n’est pas forcément le cas de Joe le développeur à qui on aura demandé 36 choses en même temps.
Je fais davantage confiance à un outil éprouvé avec succès sur des milliers de projets qu’un outil développé sur un coin de bureau, malgré toute la bonne volonté de son concepteur.
C’est également un risque certes mais un bon outil délaissé aura tout de même le mérite de fonctionner … et d’avoir davantage de chances de trouver un repreneur.
Une remarque intéressante a également émergé de l’atelier : faut-il utiliser un framework CSS avant ou après que la créa graphique ait été établie ?
Je réitère ma réponse : l’idéal est que tout soit pris en charge le plus tôt possible. Autrement dit, intégrer les contraintes du framework dès la conception graphique est un gros atout. Le découpage de la maquette n’en sera que facilité et ça évitera tout bricolage.
Certains outils l’ont d’ailleurs bien compris en proposant des supports pour graphistes au format PSD, Visio, Fireworks etc.
Feuilles de dessin pour 960 Grid System
Conclusion
Quoiqu’il en soit, les frameworks CSS sont à mon avis promis à un bel avenir dès lors que les critères d’industrialisation auront débarqué au sein des agences Web.
Aujourd’hui une petite agence a tout à gagner à maîtriser de tels outils et à annoncer qu’elle développera mieux, plus vite et moins cher. Le prix ne fait pas tout : ce sont les outils et la qualité du développement. Tous les frameworks cités sont également des logiciels libres.
J’espère que cet aperçu rapide aura ouvert les yeux à certains d’entre vous. Je suis preneur de vos retours, surtout en entreprise. Ça vaut également pour celles et ceux qui ne sont toujours pas convaincu de l’intérêt des frameworks CSS
Remarque : il y avait 2 ateliers complémentaires à Paris-Web :
Commentaires
Développement efficace avec les frameworks CSS http://tinyurl.com/5hygg4
Excellent, j’avoue faire parti de ceux qui ne connaissaient pas les framework css, je vais m’y plonger a corps perdu dés ce matin.
merci
Yeah, punaise je kife ton article dude ^^. (Prem’s).
@stéphane rien que ça ! Tu m’en diras des nouvelles
Très bonne introduction aux frameworks CSS, cependant je t’avouerais que je reste un peu sur ma faim car les exemples sont toujours assez triviaux et assez éloignés des templates que peut fournir un graphiste.
20cent me disait justement avant ton atelier qu’on peut pas les utiliser dans toutes les situations, particulièrement dans celles où le graphiste n’a pas travaillé avec une grille. Je fais encore aussi un peu d’allergie aux classes pas vraiment sémantiques des frameworks mais 20cent me conseillait de justement doubler les classes afin de rajouter de la sémantique. Du coup je considère les classes des frameworks CSS maintenant plutôt comme des ajouts un peu comme les microformats qui sont juste là pour te faciliter la tâche.
As-tu des exemples d’utilisation sur des sites en production ? Pour avoir été regarder la feuille de style du dernier projet d’Andy Clarke - http://forabeautifulweb.com - on peut voir qu’il prend des morceaux de frameworks comme Blueprint comme base de travail.
Bien qu’ayant déjà utilisé BluePrint sur des projets, j’ai quand même décidé de me rendre à ta présentation car je voulais avoir l’avis d’autres personnes sur les framework CSS et en découvrir d’autres.
Je n’ai pas été déçu, ce fut très instructif et j’y ai découvert Tripoli que je ne connaissais pas. En poussant mes recherches j’ai également découvert BlueTrip CSS dans la foulée.
Donc merci pour ton partage d’expériences.
Ha j’oublié …
Je suis complètement de l’avis qu’il faux sensibiliser le graphiste à l’utilisation des frameworks CSS.
Je l’ai bien compris en tant qu’ancien développeur (je suis maintenant graphiste freelance). Aujourd’hui lorsque je design une page, je travaille toujours à partir d’une grille que je génère grâce au constructor de BluePrint.
Je pense qu’un intégrateur qui travaillerait avec un framework CSS y verrai beaucoup d’avantages car cela lui faciliterai probablement la tâche.
Si ça vous plaît y a Yahoo qui fait un truc vraiment bien : http://developer.yahoo.com/yui/grids/
Coucou,
Les frameworks CSS sont hyper pratiques, surtout en ce qui concerne le reset. Je pense (et je suis loin d’être le seul) qu’il faut quand même se méfier car ils bafouent complètement la sémantique d’un site.
Ainsi, je tends à minimiser l’utilisation des span-* dans Blueprint, par exemple, au strict minimum, et je lui préfère des classes (ou identifiants) que j’ai moi même définis, avec des noms plus explicites (#menu, .navigation, …). Ca n’empêche pas de profiter des autres avantages comme la dynamique verticale inhérente au framework (s’il est bien fait :D).
Jetez un coup d’oeil ici pour en savoir plus : http://mondaybynoon.com/2007/08/27/please-do-not-use-css-frameworks/
[...] Thomas Parisot - Développement efficace avec les frameworks CSS [...]
J’avais regardé il y a quelque temps.
Ok pour le reset et les correctifs IE qui sont une agrégation de techniques déjà largement répandues. Mais je reste rétif à leur implémentation des grilles : on se retrouve quand même à coder de la présentation dans le code HTML comme au temps des tables.
@Franck En exemple de site entièrement bâti sur Blueprint j’ai Emu Nova. C’est perfectible mais j’ai gagné beaucoup de temps.
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.
Oncle Tom, je suis d’accord que c’est pratique quand tu développes seul de pouvoir facilement créer des dispositions sans avoir à mettre les mains dans les CSS ou autre. J’utilise Blueprint sur mes projets personnels car je le trouve très efficace en ce sens.
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”
Oncle Tom, encore merci pour cet atelier.
Tu m’as vraiment donné envie d’aller voir cela de plus près même si comme beaucoup, je n’apprécie pas du tout que la mise en forme se réalise via l’ajout de classe non-sémantique dans le code html. Cette pratique est à l’opposée du principe de base du CSS (ou alors j’ai rien compris :-)). Comment dès lors proposer un style switcher ou inclure un même code html sur deux sites aux designs différents ?
Bref, je testerai blueprint prochainement et je crois que beaucoup de choses dépendront des possibilités offertes par le compressor et le generator.
Et même, si au final les frameworks ne me séduisent pas, l’étude des fichiers CSS pourra, je l’espère, me donner quelques bonnes pratiques de développement à suivre.
@djib quand tu développes seul mais en équipe. Sauf qu’en équipe tout le monde doit apprendre à s’en servir. Mais tout le monde ne peut pas le faire.
Après clair qu’un bon intégrateur réussira : ça ne changera pas ça. Par contre si ça lui permet de réduire de 25% sa charge de travail, pourquoi passer à côté ?
Et excuse-moi, travailler sur une grille n’est pas brider la créativité (on a eu ce débat pendant l’atelier) : organiser visuellement l’information c’est pas brider.
La reprise de CSS avec un framework bien documenté est à plus facile qu’un code créé par un individu lambda (tous les intégrateurs ne sont pas bons) : tu as de la doc sur le Web, tu as des listes de diffusion, des forums … ce que ne proposera jamais l’autre alternative.
Pour l’inspection des tailles, un coup de Firebug avec son inspecteur HTML et c’est réglé. C’est un faux problème qui existait déjà avant et qui existera toujours.
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.
#headerou#footerpar 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.
Oncle Tom, je crois infiniment plus aux outils CSS de type SASS (HAML), avec des variables CSS, une écriture “naturellement” indentée et une lisibilité accrue, qu’à des frameworks CSS. Je serai encore plus convaincu par CSS3 !
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.
Je ne connaissais pas HAML mais ça m'a l'air sympa.
Avec CSS3, j'en n'ai pas parlé dans mes slides, mais je pense qu'on peut s'attendre à voir les frameworks gagner davantage en maturité puisqu'il sera du coup plus facile d'hériter des styles définis.
Dans tous les cas, SASS ou frameworks, le but est le même : gagner du temps et se faciliter la vie. C'est ce qu'il faut en retenir. Les 2 ont de l'avenir.
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 !
Framework CSS : Pour ou contre ? http://tinyurl.com/5hygg4 tKaap utilise Blueprint
Hello Thomas, pour notre projet tKaap.com nous avons aussi utilisé Symfony et BluePrint, et cela nous a bien aidé
On détaillera davantage sur notre blog 
Hey cool symfony c’est bon pour la santé ! J’attends vos retours (à toi et Sylvain). J’aime bien connaitre l’opinion d’outils que j’utilise et apprécie.
Salut à tous,
je ne sais plus où donner de la tête! Je suis confronté à un problème, qui en réalité, n´en est pas un pour ceux ou celles qui se connaissent en CSS. Ce qui n´est pas mon cas. Voilà, j´essai de modifier en vain 2 themes de Drupal, en l´occurrence, basic et bluetrip téléchargés sur “http://drupal.org/project/basic et http://drupal.org/project/bluetrip pour qu´en lieu et place du logo bleu de drupal et le nom du site j´aie toute la place en en-tête pour placer une bannière sur toute sa longueur (de l´extrême gauche à l´extrême droite). J´ai demandé de l´aide dans un anglais approximatif depuis 2 ou 3 jours sur drupal.org mais jusque là aucune réaction. Une âme charitable pour me sortir de ce casse-tête? Je vous en serais éternellement reconnaissant.
Merci
[...] suis encore tout esbaudis par la découverte de 45+ frameworks CSS que tout webdesigner devrait connaitre qui liste une palanquée de bibliothèques CSS et d’outils pour générer des grilles de mise [...]
Répondre