La dernière rencontre Twitter de la communauté du Webdesign francophone (WDFriday et #wdfr) était consacrée aux frameworks CSS. J’ai été surpris de voir à quel point ils semblent peu employés au regard des critiques dont il font l’objet. L’argument le plus valable que j’ai relevé est qu’un bon intégrateur Web n’a pas besoin de framework CSS. Ce n’est pas faux et c’est d’ailleurs valable pour tous les frameworks ! Un bon développeur front-end n’a pas besoin de jQuery ou de Mootools et un bon développeur Web n’a pas besoin de Symfony ou de Ruby On Rails, nous sommes bien d’accord.
Chacun cherche son framework
Pourtant à la lecture des différentes interventions, il semble que de nombreux participants ne réinventent pas la roue à chaque projet. Les reset CSS sont très utilisés ainsi que les feuilles de style dédiées à un aspect particulier de la mise en page : typographie, formulaires, impression, etc. La pierre d’achoppement semble plutôt se situer au niveau du fichier grid.css qui contient généralement les classes pour le positionnement des blocs sur la grille de mise en page.
Des grilles plusieurs fois millénaires
La discussion s’est d’ailleurs rapidement transformée en débat sur le bien-fondé de l’utilisation des grilles dans le Webdesign. Autant je trouve qu’il est intéressant de chipoter sur les détails de l’utilisation des listes de définition, autant la question de savoir si l’on doit mettre une grille dans son design me semble quelque peu déplacée. Les grilles de mise en page sont utilisées depuis plusieurs milliers d’années. On en trouve la trace dans les premiers documents écrits sur le bois, le cuir, la pierre, l’argile, le papyrus, etc. Je me demande même s’il est possible de travailler sans grille…
Comme le dit si bien André Gide, L’art nait de contraintes, vit de luttes et meurt de liberté. Ce qu’on pourrait traduire librement — pour ceux qui seraient obsédés par l’occupation mémoire de la citation d’origine — par : Sans contrainte, l’art n’est rien ou encore par Trop de liberté, nuit.
Développeur depuis 1337 ?
Pour revenir sur le rejet dont souffrent les Frameworks CSS, j’ai le sentiment qu’ils sont victimes de leur succès (je sais, c’est paradoxal) : avoir mis à la portée du plus grand nombre des techniques à l’épreuve des balles pour produire des pages Web, pas toujours très jolies, mais souvent efficaces et à moindre coût. Faut-il y voir également une vision un peu élitiste de la part de la communauté des développeurs Web francophones ? Ça s’pourrait ^^
Un pont entre développeurs et graphistes ?
Les frameworks CSS ont réussit à se mettre les développeurs Web et les graphistes à dos, ce qui leur fait désormais un point commun qui leur permettra de discuter devant la machine à café, c’est un début.
En attendant que des petits naissent de cette nouvelle idylle, je conclurai en faisant remarquer qu’au final, les intégrateurs Web sont les seuls à apprécier les avantages procurés par ces frameworks. Leurs arguments souvent pragmatiques n’ont pas été entendus lors de cette rencontre ; leur place dans le flux de production Web les rend peut-être plus capable que les autres d’accepter des points de vue différents, sans imposer le leur.
Se retrouver entre les développeurs et les graphistes demande certainement des nerfs d’acier et une bonne dose d’humilité ^__^
Je n’ai pas participé à cette discussion. Je souhaite juste revenir sur l’utilité d’utiliser une grille.
Oui, l’utilisation des grilles existe surement depuis que le livre existe.
Mais tous les projets ne nécessite pas forcement une grille. Et surtout, c’est du « concept » et du « design » que découle la grille. Et pas l’inverse.
Les framework ont ce défaut d’imposer une grille au designer (je généralise, certains framework sont plus ou moins souple), alors que c’est au designer de créer sa grille en fonction de son projet (et si une grille est nécessaire, mais souvent, dans tout travail éditorial, elle l’est).
Et ensuite, quand la grille est définie, écrire son propre grille.css n’est vraiment pas sorcier.
Les framework sont à l’image du capitalisme galopant : très efficace pour pondre une maquette « carré », « acceptable » en 1 journée et ensuite gagner du temps dans la collaboration avec l’intégrateur. Mais ils créent une sorte d’uniformité qui manque cruellement d’originalité. Un peu comme le design de ce blog, rigoureusement impersonnel.
Personnellement je n’aime pas les framework quels qu’ils soient, je ne déplore pas leur utilisation puisqu’elle peut être bénéfique pour certains surtout au niveau du gain de temps. Mais à cela il faut retirer le temps d’apprentissage, et surtout savoir si l’on maîtrise à fond l’outil que l’on utilise ?!
Il m’est d’avis que si chaque site se veut différent, le css lui aussi devrait l’être (comme un peintre qui commence une nouvelle toile). Bien sur on peut avoir sous la main un reset css qu’on utilise à chaque fois, c’est une façon comme une autre de travailler.
Bref je suis plutôt contre leur utilisation, mais il en faut pour tous les goûts…
Sacripant — Jette un oeil sur http://css4design.com/framework-css-mettez-vos-grilles-au-pas et plus généralement sur les billets taggués Frameworks CSS sur ce blog. Tu y verras que mon avis sur les grilles et les frameworks CSS est beaucoup plus nuancé qu’il n’y parait au premier abord.
J’essaie en général d’éviter la pensée unique dans les métiers du Webdev (les frameworks c’est nul, mais les frameworks JS ou PHP, c’est de la balle, etc.) au risque de me disperser un peu en mettant plusieurs idées parfois contradictoires dans un billet.
Disons que mon-avis-personnel-à-moi-que-j’ai est la part humaine et chaleureuse de ce blog : il faut bien ce design rigoureusement impersonnel pour refroidir mes ardeurs ^^
Bonjour,
il est beaucoup question en ce moment de « Lean IA » , de méthode agile et de prototypage (voir cette présentation à l’euroIAVI : Getting out of the deliverables business ou encore à Paris Web la présentation de Stéphanie Troeth).
C’est une méthodologie qui mérite vraiment que l’on y jette un oeil, caricaturalement cela donne :
Définition audience/objectif -> Sketch papier -> proto fonctionnel -> test utilisateur -> sketch papier -> proto fonctionnel -> test utilisateur and so on.
Ma modeste interprétation est d’utiliser des framework CSS YAML & javascript (jQuery) + un CMS (SPIP) ou un framework php (ZEND) pour permettre de faire le pont entre sketch papier et prototype fonctionnel, ce n’est pas la panacée mais cela fait le job et je peux vous assurer que sans framework CSS c’est mission impossible : tout le cycle repose sur de l’itératif court (très court même…).
On peut rajouter le graphiste dans la boucle (IA le fait mais leurs architectes de l’information sont à Zurich et les graphistes au Japon et le décalage horaire leur permet de le faire) et là, c’est pareil, il vaut mieux utiliser des outils plus orientés prod (Fireworks ou Illustrator CS5 par ex.)
Cela permet, en plus de l’ergonomie et de la navigabilité, de débugger très en amont le js, l’interopérabilité, la capacité du client à fournir le contenu, bref de faire ce que l’on appelle un… Prototype !
De mon point de vue, le terme de designer prend tout son sens à ce moment là.
Peut-être que la question n’était pas « Utilisez-vous un framework CSS ? » mais « Pourquoi utiliseriez-vous un framework CSS ? » (et accessoirement « Prototypez-vous et si oui, comment ? »).
Enfin, et pour être tout à fait honnête, ce n’est pas le fait de prototyper qui m’a fait venir aux framework CSS, c’est la question suivante : Comment faire pour rester en vie professionnellement en tant qu’intégrateur alors que PSD2HTML existe ? (je n’ai pas vu sur le marché français de concurrent sérieux en terme de rapport qualité — très élevée — /prix — très bas —).
J’ai trouvé deux réponses : premièrement sous-traiter et marger dessus, deuxièmement changer radicalement mes méthodes de travail pour être beaucoup plus compétitif, ce qui m’a amené au framework CSS et au prototypage.
Bien à vous, mes très chers
intégristesintégraphistes.Un développeur mauvais ou pas, favorisera toujours un framework pour développer. C’est un peu une hérésie de dire qu’un bon développeur n’a pas besoin d’un framework.
Un bon développeur déteste réinventer la roue, refaire l’inutile etc. Un framework évite tout ca, un framework est éprouvé, un framework évite les failles les plus communes etc.
Votre intro est totalement à revoir, elle ne m’a même pas donné l’envie de lire plus…
manu — C’est assez étonnant de voir que vous ne voyiez pas que nous partageons le même avis sur les frameworks. Quant vous aurez parcouru les interventions du WDFriday, vous vous rendrez compte que les plus farouches adversaires des frameworks CSS sont les développeurs eux-mêmes… D’où l’introduction cavalière de ce billet dont l’ironie vous aura sans l’ombre d’un doute échappée.
Juste pour rebondir sur ce que dit Manu concernant la phrase « Un bon développeur déteste réinventer la roue, refaire l’inutile etc. »
Sur le fond je suis d’accord et j’utilise des frameworks, mais d’un point de vue purement pédagogique (je suis autodidacte et curieux) il est parfois bon de réinventer la roue pour précisément en comprendre le fonctionnement.
Désolé pour le hors-sujet 🙂
Erik — Tu n’es pas du tout hors sujet, bien au contraire. Je jette souvent un oeil sur les frameworks CSS pour voir comment ils sont fait. C’est toujours très instructif de lire le travail de quelqu’un qui a réfléchit parfois longtemps sur un aspect spécifique du métier.
Je vante souvent les mérites des FW CSS, mais en réalité, je repars souvent presque de zéro car j’ai tendance à changer régulièrement de méthode de travail : si ça rapportait, je serais peut-être testeur de framework CSS 😉
Perso, je n’aime pas réinventer la roue…Certainement parce que je ne suis pas un super bon développeur, et que je manque souvent de temps. 🙂
Je pense sincèrement qu’il y a beaucoup d’intérêts à utiliser des FrameWorks… Les articles sur tes blogs à ce sujet listent bien les avantages d’un FrameWorks…
Maintenant, je dirai qu’en effet, réinventer la roue est une bonne chose d’un point de vue pédagogique…
Certaines choses ont été « inventées » pour se simplifier la vie…Pourquoi s’en priver?
Ce dernier WDFriday avait lieu pendant Paris Web dont certaines conférences répondent à ton billet : ne ratez pas les vidéos et supports de conf qui seront prochainement publiés sur le site dédié !
Un bon développeur sait s’équiper des outils qui lui évitent de perdre son temps à recommencer cent fois la même chose, pour mieux le consacrer aux tâches délicates et spécifiques qui réclament son attention et le meilleur de ses compétences. Les frameworks CSS ne sont que des outils qui aident à être plus efficace ; il est dommage de s’en priver.
En attendant, celles et ceux qui y sont contre ou qui n’arrivent pas encore à s’y mettre apprécieront la méthode Daisy, qui permet déjà de mieux organiser son code, pour plus d’efficacité : Méthode Daisy : les CSS feuille à feuille.
L’utilisation de grilles pour la mise en page est ancienne… Ne ratez pas cette excellente conférence d’Anne-Sophie Fradier qui parlait justement de composer avec des griles en réussissant à mettre tout le monde d’accord : La macrotypographie de la page Web. En voici déjà un compte-rendu assez complet.
La
grid.cssdes frameworks est justement ce qui permet d’accorder graphistes et intégrateurs, en fournissant des grilles de référence, prêtes à l’emploi. Car contrairement à prétend sacripant, ce n’est vraiment pas trivial de coder une grille CSS robuste.Enfin, d’accord avec Nicolas, se pose la question de la rentabilité et de la survie financière de l’intégrateur. Pendant combien de temps encore les DA (haha) pensent-ils continuer trouver, pour le même prix, des intégrateurs acceptant de tout coder à la main, sur mesure, sans outil ni méthode (sans grille ni framework) ?
Il me plait, merci beacoup! Les framework ont ce défaut d’imposer une grille au designer (je
généralise, certains framework sont plus ou moins souple), alors que
c’est au designer de créer sa grille en fonction de son projet (et si
une grille est nécessaire, mais souvent, dans tout travail éditorial,
elle l’est).