Pourquoi les grilles « responsive » et les frameworks CSS sont une mode qui passera

Je pense sincèrement que le « tout fluide » ne devrait pas être généralisé comme une bonne pratique. Les grilles fluides des designs « responsive » sont inadaptables. Les frameworks Bootstrap, Knacss et consorts de même.

Les grilles fluides sont inadaptables

Prenons l’exemple d’une grille de douze colonnes servant à la conception d’un design de 960 pixels de large. En responsive Web design, le nombre de colonnes de la grille reste invariable sur tout type d’écrans. Sur les terminaux mobiles les plus étroits comme sur les moniteurs extra-larges dernier cri, on travaillera donc toujours sur les mêmes douze colonnes. Bien. Ça a l’avantage de la simplicité.

Sur un écran d’ordinateur de taille moyenne, la grille contient donc douze colonnes de soixante pixels plus les gouttières. Ces soixante pixels seront affichés sur environ deux centimètres : de la place pour quelques caractères d’une taille raisonnablement lisible pour un œil humain.

Prenons maintenant le cas d’un téléphone étroit à l’ancienne. L’affichage est rendu sur une largeur de 128 pixels mais laissons de côté les pixels. L’écran mesure trois centimètres : de la place pour environ quatorze petits caractères par ligne. Les colonnes de notre grille sont maintenant compressées jusqu’à 1,9 millimètre de large. Selon vous, cher lecteur, à quoi sert une grille avec des colonnes de 1,9 millimètre de large ? Selon moi : à rien.

Et les concepteurs des frameworks Bootstrap et Knacss en conviennent également puisque en deçà d’une certaine largeur ils proposent carrément de désactiver les colonnes par media query. Regardez cet exemple pour Bootstrap et cet autre pour Knacss, chargez les pages puis réduisez la largeur de votre navigateur.

Donc une grille fluide prévue pour un écran de quinze pouces ne s’adapte pas aux écrans étroits.

Essayons alors les grands écrans et prenons un magnifique moniteur extra-large de vingt-sept pouces : soixante centimètres de large ! Notre grille s’étire cette fois-ci comme un élastique pour faire des colonnes de… 3,75 centimètres. Comment pourrait-on travailler finement sur des colonnes plus larges qu’un téléphone ?

En résumé, une grille fluide conçue sur un écran de quinze pouces ne permet de faire du bon design que sur des écrans de quinze pouces. Bonjour la fluidité !

Alors à quoi sert une grille fluide ? La grille fluide sert à conserver la même apparence quelle que soit la résolution, c’est-à-dire le degré de finesse des pixels (dpi). Par exemple si les écrans quinze pouces dans deux ans proposent des résolutions triples de celles d’aujourd’hui, les grilles fluides s’afficheront toujours correctement.

Les grilles « frameless » sont la solution

D’abord une démonstration : ouvrez le site des grilles Frameless. Faites varier la largeur de votre navigateur. Pour visualiser la configuration la plus large et celle la plus étroite, utilisez Firefox ou Opera (pas Chrome) puis dézoomez et zoomez.

« Frameless », c’est juste une idée. C’est l’idée que l’œil humain ne change pas fondamentalement de perception de ce qui est large ou fin selon qu’il regarde un écran large ou un écran fin. La largeur d’une colonne de contenu doit être en adéquation avec notre œil et non avec le terminal. Et donc on ne doit pas rendre les blocs de nos pages Web proportionnels à la largeur du terminal (%) mais les garder dans une proportion relative à la taille par défaut des caractères (em).

Pourquoi le caractère ? Parce qu’il reste nécessairement dans une fourchette qui fait sens pour l’œil humain. Et parce qu’il est malgré tout plus souple que les unités « réelles » comme les centimètres.

La taille par défaut d’un caractère est le bon indicateur du degré de finesse ou de grosseur que le constructeur du terminal a voulu donner à l’affichage sur son écran. Il représente toujours l’unité de ce qui est lisible pour l’œil humain. C’est sur lui qu’il faut tout construire.

J’ai ensuite une critique à l’endroit des « frameworks CSS » Bootstrap et Knacss.

Les frameworks CSS Bootstrap et Knacss confondent fond et forme

Les frameworks CSS Bootstrap et Knacss fournissent des classes CSS servant à construire rapidement une mise en page préfabriquée. Ainsi il suffit d’adjoindre une classe « span2 » (en syntaxe Bootstrap) à un élément pour que ce dernier prenne une largeur de deux colonnes de la grille. Lire à ce sujet un tutoriel pour Bootstrap et celui de Knacss.

Personnellement je vois un réel problème à utiliser des informations de type habillage dans le contenu. C’est une entorse à la séparation du fond et de la forme. Cela se paie forcément. Je prends l’exemple d’un élément « article » dont le design est conçu sur un ordinateur doté d’un écran de taille moyenne et qui fait huit colonnes de large :

<article class="span8">…</article>

Imaginons un rendu théorique avec grille et sur mobile. Les frameworks CSS sont « responsive » et donc les huit colonnes rentrent dans l’écran du téléphone. Une colonne seule devient certes inutilisable mais avec huit colonnes ce sera peut-être encore lisible. Sauf que, manque de chance, le designer crée une déclinaison aménagée du design pour mobile et demande à passer l’article sur dix colonnes. Alors que fait-on ? Faudrait-il publier un code HTML différent pour la version mobile ?

Ou bien un exemple plus trivial encore : notre designer change d’avis et nous demande de passer l’article sur neuf colonnes. Voilà une modification de pure forme qui demande de changer le contenu.

Enfin bref je ne vais pas faire le topo sur la séparation du fond et de la forme. Vous lecteur qui me lisez vous savez tout cela, c’est le fondement du métier. Mais pourquoi a-t-il suffit des quelques mots à la mode « responsive » et « framework » pour vous le faire oublier ?

Les « mixins » de LESS CSS sont une solution

Le travail de synthèse réalisé par les concepteurs des frameworks CSS est toutefois excellent. Les classes CSS qu’ils fournissent devraient être non pas des classes mais des groupes de propriétés réutilisables dans les règles CSS. CSS ne permet pas la réutilisation de telles choses, mais LESS le peut et les appelle « mixins ».

LESS CSS est un préprocesseur pour CSS écrit en JavaScript.

Jusqu’à il y a quelques jours j’avais des griefs à l’encontre de cette technologie. Ainsi on peut l’utiliser directement dans les pages Web et laisser le navigateur préprocesser, mais :

  1. C’est forcément lourd côté navigateur d’interpréter la syntaxe LESS via du code JavaScript. Et puis il faut mettre la ressource JavaScript dans l’élément HTML « head » pour forcer son exécution avant l’affichage de la page, ce qui est un défaut en performance.
  2. Si on désactive le JavaScript sur le navigateur, la page n’est plus du tout stylée.
  3. Les robots des moteurs de recherches n’interprètent surement pas les fichiers LESS, ils ne peuvent donc pas scanner le site normalement. Il est en effet très probable que Googlebot utilise les CSS pour affiner son évaluation de quels contenus sont essentiels dans une page Web.
  4. LESS n’est pas un standard. Publier (ou archiver) un site basé là-dessus, c’est s’exposer à des soucis de pérennité.

Il existe une solution pour exécuter LESS CSS côté serveur et servir au navigateur des ressources CSS, mais elle est complexe à déployer et peut-être même infaisable sur des hébergements mutualisés modestes. De plus, le quatrième grief est valable aussi pour du préprocessing côté serveur.

Et donc j’en restais là jusqu’à ce qu’un ami me recommande une solution tournant sur son Mac OS : LESS.app. Le principe est de compiler les fichiers LESS en CSS directement sur la machine du développeur Web. Ensuite sur le site la CSS résultat est incluse normalement et le site fonctionne donc sans préprocesseur. Je me suis mis à la recherche d’une solution équivalente pour Linux et j’ai trouvé Lé-css sorti en open-source par Lukas Dietrich le mois dernier. L’outil n’était pas utilisable dans mon cas et j’ai dû le modifier pour y ajouter un fichier de configuration ainsi que la capacité de travailler sur plusieurs projets en même temps.

Le résultat est Less Now. C’est du java, ça tourne sur tous les systèmes d’exploitation.

Dans le travail de création d’un site Web, Less Now ne représente pas une opération supplémentaire. En effet, depuis que Google parle de performance il est devenu normal de mettre en production un fichier CSS minifié donc différent du source original. Là nous avons un outil qui fait juste « un peu plus » que minifier.

PS. Je sais, ce blog n’applique aucun des conseils que je donne. Les CSS sont faites à la main, c’est du Web 2.0 à l’ancienne, et la partie principale du site est « responsive ». Cependant j’ai eu une révélation il y a quelques jours et j’ai voulu la partager.

19 Responses to Pourquoi les grilles « responsive » et les frameworks CSS sont une mode qui passera

  1. Merci pour ce billet très très détaillé!

    Je ne suis ni calé en script ni en language HTML ni en autre chose qui est un lien quelconque avec la programmation et l’informatique. Toutefois, ce billet m’a permis d’élargir mes connaissances notamment sur les CSS !

  2. Mantis says:

    J’ai lu votre article et je suis en total désaccord avec vous.

    Au contraire le responsive est l’avenir du web. Un seul développement qui s’adapte à tout les écrans sera un gain de temps et d’argent considérable. Meme si le résultat est moyen il sera privilégié car économique.

    En tout cas pour le reste vous avez votre point de vue je le respecte mais je rappelle que le but d’un framework est de guider, le code est libre alors rien ne vous empeche de le modifier.

    PS : regardez du côté du framework Foundation qui est plus libre tout en proposant des solutions à la bootstrap.

  3. Bonjour Mantis. Vous dites que le “responsive” fait gagner du temps. Ce n’est pas mon expérience. Pour ma part je vais plus vite avec une grille frameless. Je peux citer deux caractéristiques du fluide qui font perdre du temps :

    1. Les fichiers CSS “responsive” contiennent de nombreuses valeurs calculées difficiles à lire. Par exemple le sens d’une valeur comme “12.5316456%” ne saute pas aux yeux. Cela peut certes être pallié par des commentaires mais ça reste difficile à lire. Et donc la maintenance est plus ardue.
    2. De plus, si l’on veut que la grille soit élastique, cela incite à utiliser de nombreuses media queries pour de nombreuses largeurs différentes : tel bloc devra être ajusté à partir d’une largeur d’écran de 84.375em, tel autre pour les écrans de 87.5em, un troisième pour ceux de 78.125em. Cela aussi est difficile à maintenir et tout simplement long à développer.

  4. Florian says:

    creapage.net, Je ne suis absolument pas d’accord avec vous. Essayez le framework skeleton qui évolue sur 960px 16 colonnes et vous verrez à quel point il est facile de créer un site responsive, de plus ce framework possède 3 adaptations de tailles d’écran différentes et croyez moi cela correspond à tous les écrans de tablettes et mobiles .

  5. Cpag says:

    @Florian : Je viens de regarder le framework “Skeleton” de votre site theme-responsive.com. La page dédiée mentionne : “Notre site est basé sur ce framework” alors j’ai simplement regardé le comportement de cette page-là. Et alors c’est amusant parce que… elle n’est pas “responsive”.

    Le “responsive Web design” a été défini par Ethan Marcotte dans son livre dont je recommande la lecture : l’auteur est aussi passionnant qu’amusant et l’air de rien son argumentaire change (en mieux!) notre manière de voir le Web design.

    Et donc le responsive Web design est par définition fluide. C’est-à-dire proportionnel. Dans votre site Web la règle CSS suivante s’applique :

    .container {
    	width: 960px;
    }
    

    Sur les écrans étroits par media query elle devient :

    .container, .white-space {
    	width: 768px;
    }
    

    Au passage, en ces temps de course au pixel infime, il serait plus prudent d’abandonner les pixels.

    Mais bref. Votre site Web n’est pas “responsive”. Si vous souhaitez un exemple de grille “responsive”, regardez plutôt le comportement de la partie principale de mon site qui va de 128 à 1580 pixels (oui je sais même sur les pixels mon site n’applique pas encore mes propres conseils).

  6. eQRoeil says:

    Bonjour,
    je partage quelques unes de vos réflexions concernant les défauts des grilles css.
    Je préfère moi aussi des breakpoints en em (la mise en page s’adapte lorsque le visiteur zoome)
    En revanche :
    – il est normal qu’il n’y ait plus qu’une colonne de contenu sur petit écran … on n’a pas la place pour plus (sauf dans de rares cas et certains frameworks proposent cette option, griddle par exemple est très souple et adaptable)

    – plus généralement, dans vos “critiques” ou questions – justifiées – vous remettez en cause un système de nommage (span2 pour bootstrap, w33 pour knacss par exemple) plus que son fonctionnement.
    Ces nommages sont pratiques ( et le 12.53… peut être nommé w12) lors de la phase de conception mais rien n’empêche de renommer ces classes différemment pour permettre plus de lisibilité ou maintenabilité et ainsi permettre des modifications sans changer le HTML… c’est là que les pré processeurs comme LESS ou SASS peuvent aider avec @extend (pour SASS)

    – la manière la plus simple d’expliquer comment fonctionne une grille est bien d’utiliser un nommage qui reprend les proportions de cette grille, c’est également la manière la plus simple de la mettre en œuvre… un nommage plus “safe” est possible… laissé au choix de l’utilisateur.
    C’est le meilleur équilibre à mon avis entre souplesse (pour le designer), temps d’apprentissage et facilité de mise en oeuvre.

    Quant aux changements en phase de création… le grille doit servir un contenu et donc être choisie en fonction de celui-ci… et ne pas changer en cours de route.

    Si réel besoin, avec un CMS qui gère le contenu, c’est un template à changer, pas toutes les pages…

    Dans le cas d’une refonte, il faudra certainement mettre les mains dans le code HTML…

    S’il existait un système parfait nous n’aurions pas tous ces systèmes de grilles ou frameworks différents, il faut trouver celui qui nous est le plus naturel, celui qui correspond à notre manière de travailler 😉

    “une mode qui passera” … oui avec flexbox, grid-layout, regions et exclusions…. dans quelques années !

  7. Cpag says:

    Bonsoir eQRoeil et grand merci pour votre commentaire.

    Concernant les écrans de smartphones j’avoue que je n’ai pas assez d’expérience. Il me semble néanmoins qu’en mode paysage il y aurait de la place pour deux ou trois (ou quatre?) colonnes non ? En tout cas la critique tient pour les grands écrans. 🙂

    Sur les frameworks CSS c’est le mode de pensée qui est à l’envers : on ne devrait pas piloter le positionnement CSS depuis le code HTML. Un renommage des classes CSS avec des noms plus sémantiques ne sera pas toujours possible. La classe qui représente deux colonnes de large par exemple a de fortes raisons d’être utilisée plusieurs fois et pour des éléments qui ne partagent pas un même sens sémantique. J’essaie en ce moment un autre mode de travail : des variables LESS définies pour toutes les largeurs de colonnes : @1c, @2c etc. (je les génère avec un tableur). Plus cohérent.

    Je maintiens que les frameworks devraient fournir des mixins et des variables, pas des classes CSS. Ce devraient être des frameworks LESS en fait. Je pense que CSS est de trop bas niveau pour qu’on puisse créer un framework dessus proprement.

  8. Erwan Tanguy says:

    Je partage votre point de vue. L’erreur la plus fréquente est d’appeler “responsive design” des sites qui ont en réalité été réalisés avec des “switch design” – ce que je fais généralement et ce que fait le site de Florian.

    Pour des sites en responsive, la question des grilles me semblent très importantes et votre démonstration est très justes. Reste à tester Less ou d’autres.

    Merci pour votre réflexion !

  9. charlie Chan says:

    Merci ! tout à fait le genre d’article qui te fait progresser d’un coup.

  10. Cpag says:

    Merci pour les mercis !

    J’avoue avoir retiré les derniers échanges avec Florian qui étaient hors sujet et pas constructifs. Cet article suppose la définition de “responsive” déjà acquise. Pour ceux qui n’ont pas lu Ethan Marcotte, la définition de “responsive” est ici.

  11. Raphael says:

    Bonjour et merci pour cette analyse très intéressante sur de nombreux points de vue. Il y a de très bonnes choses dans cet article en effet.

    Cependant, dès l’introduction, j’ai un peu de mal à comprendre ce constat : “En responsive Web design, le nombre de colonnes de la grille reste invariable sur tout type d’écrans.”.

    En réalité, c’est exactement l’inverse : l’objectif du RWD est justement de s’adapter à toutes les résolutions, il est donc nécessaire que le nombre de colonnes se réduise si l’écran se réduit (passer de 5 à 4 colonnes, puis 3, puis 2 puis une seule par exemple).
    En voici quelques illustrations :
    http://www.alsacreations.com/
    http://www.alsacreations.fr/
    http://www.thinkmobilefirst.net/table/1.html (pour montrer le principe épuré)

    Sur ce point, bien évidemment les frameworks ne peuvent pas anticiper votre design et son nombre de colonnes, ni vos “points de rupture”, il faut donc envisager cette adaptation du nombre de colonnes en sus du framework.

    L’autre point qui m’a titillé est celui du non respect du fond et de la forme.
    Je t’avoue de depuis que je fais de l’intégration (un paquet d’années), j’ai toujours été très concerné par les standards, l’accessibilité et la sémantique, et que des classes HTML telles que “.rouge” ou “.left” m’ont toujours rebuté pour des questions de sémantique par exemple et de séparation “fond – forme”.

    Il se trouve cependant qu’avec l’expérience, on se rend compte que les contraintes de production et de performances ont bien évolué en 15 ans : à force de séparer radicalement HTML et CSS, on ne crée que des éléments non modulables et non réutilisables. C’est pourquoi des sites comme Facebook dénombrent 261 valeurs de bleu (!), ou que 12% des plus gros sites mondiaux comptent plus de 50 occurences de “!important”.

    Ces aberrations peuvent être évitées en utilisant judicieusement des classes (ou classes multiples) sur les éléments, par exemple h2 class="h3-like row highlight". Ces classes peuvent être réutilisables et n’influent pas dans la “sémantique” : il s’agit toujours d’un h2 pour l’Agent Utilisateur.

    Je te conseille vivement de suivre les travaux de Nicole Sullivan (ex-Yahoo!) sur le sujet (qu’elle a appelé “OOCSS”), notamment une conférence “our best practises are killing us”, ainsi que le livre “CSS maintenables” de Kaelig Deloumeau-Prigent (http://www.css-maintenables.fr/).

  12. Cpag says:

    Bonjour Raphaël, merci d’être passé et grand merci pour ta réaction. Je découvre le site css-maintenables et tes arguments sur la sémantique non réutilisable m’ouvrent un nouveau champ à prospecter.

    Sur les designs “responsive”, peut-être ai-je raté des développements. Toutefois dans le cas d’une grille fluide un changement de grille à un point de rupture implique de refaire tout le positionnement. Car dans une grille fluide le calcul des largeurs de chaque bloc est relatif à son conteneur. Et l’argumentation d’Ethan Marcotte (je le cite, p. 102 : “En clair, en partant de fondations flexibles, on a moins de code à produire”) n’incite pas à changer de grille en cours de route pour tout recalculer.

    Je prends un exemple. Dans le cadre d’une mise en page pour écran d’ordinateur sur 12 colonnes :

    .container {
      width: 83.3333333%; /* 10 colonnes sur 12 */
    }
    .container .encart {
      width: 20%; /* 2 colonnes sur les 10 du parent */
    }
    

    Le contenu de .encart (un numéro de téléphone par exemple) fait que sa largeur doit rester à peu près la même. Ce n’est pas le cas de .container qui est plutôt lié à la largeur du navigateur. Et donc à un point de rupture pour tablette en portrait on décide que la grille ne fait plus que 8 colonnes de large. L’encart reste sur deux colonnes mais on est bon pour tout recalculer quand même :

    .container {
      width: 75%; /* 6 colonnes sur 8 */
    }
    .container .encart {
      width: 33.3333333%; /* 2 colonnes sur les 6 du parent */
    }
    

    Avec une grille non fluide (frameless) on définirait une seule fois une largeur d’encart sur deux colonnes, en em, sans s’occuper de la taille du parent, et l’affaire serait réglée. Je prépare un article sur le positionnement pour grille non fluide d’ailleurs (sans frameworks :p ).

    L’exemple de positionnement en tables de thinkmobilefirst (ton site je crois me rappeler) est presque magique. Fabuleux. Et je trouve le principe “semi-fluide” d’Alsacreations.com et de l’agence élégant : fluide pour les petits écrans afin de ne rien perdre de la largeur d’écran et fixe pour les plus grands. Cependant là encore la version fixe pour grand écran n’est pas fluide et donc pas dans ma critique du “responsive” (fluide).

  13. Raphael says:

    OK, je comprends bien mieux ton argument à présent.
    Tu prends le terme de “Responsive” vraiment au pied de la lettre, tel qu’il a été inventé par Ethan Marcotte, donc une combinaison “Grille fluide, Images fluides, Media Queries”.

    Et c’est là que nos conceptions divergent. En ce qui me concerne, le RWD se définit beaucoup plus simplement par “un design qui s’adapte à toute taille d’écran”.
    Selon moi, les largeurs des blocs ne doivent pas forcément être en pourcentage pour que le design soit qualifié de “Responsive”, je critique d’ailleurs le livre de Marcotte à ce sujet ici : http://www.alsacreations.com/livres/lire/1320-responsive-web-design.html (voir dans “faiblesses”).

    Bref, pour moi Alsacreations.com et Alsacreations.fr (par ex) sont des sites “Responsive”, mais si tu estimes que ce mot ne leur convient pas, appelons-les “designs adaptatifs” ou “réactifs” 😉

    KNACSS est prévu pour gérer des tailles de toute sorte (plus précisément en pixel, pourcentage ou auto), selon les préférences. Dans cet exemple (http://www.knacss.com/demos/2.html) on a bien deux blocs de largeur fixe en pixel et un troisième fluide qui s’adapte… et le tout passe sur une colonne sur petit écran. Il faudrait bien entendu ajouter des points de rupture dans un vrai projet, mais ce fonctionnement est inné au départ sur KNACSS.

  14. Cpag says:

    C’est après avoir lu ta critique que je me suis procuré le livre d’Ethan Marcotte. J’ai alors fait du responsive et puis j’en suis revenu, j’ai relu ta critique et ai suivi le lien des http://framelessgrid.com/ . 🙂

  15. Cpag says:

    Je signale le tutoriel Des grilles et des CSS : comment travailler vite et sans frameworks. Il fait suite à l’analyse présentée ici.

  16. Kaelig says:

    Bonjour,

    À noter que Twitter Bootstrap et KNACSS sont très orientés “prototyping”. Ils permettent de mettre en place des concepts rapidement, et avouent qu’ils ne sont pas une solution à tout.

    J’entends ton propos mais il me semble que tu poses une critique qui puise ses racines dans un autre contexte que celui du prototyping.

    Quand au pré-processeur CSS LESS, je le déconseille pour faire du responsive web design. Sa gestion des @media queries est catastrophique. Je renvoie les intégrateurs désireux de coder rapidement leurs designs responsive vers Sass, qui me semble être l’outil le plus approprié (pour le moment).

  17. Pingback: Responsive Web Design | Mathieu Chartier

  18. Weizu says:

    Alors, j’suis désolé de faire le hater, mais je dois dire NAAN! La “désactivation” de la grille, c’est justement ce qui rend les grilles intéressantes! Les grilles, fluides (et encore moins fixes) ne suffisent pas pour s’adapter aux supports mobiles. Mais elles permettent de gérer les colonnes et rendent la page propre sur PC et TV!! Les grilles, c’est pas seules qu’elles vont rester, mais utilisées dans le responsive design (avec les médias querys et images fluides, c’est-à-dire qui s’adaptent à la page) elles vont rester pendant longtemps dans les techniques utilisées par les web designers!!!

  19. Bien ton article, je rajoute que pour ceux qui ont un serveur mutualisé et qui ne peuvent pas installer less en natif.

    Il y a php-less, très simple d’utilisation, il faut juste inclure la classe, l’instancier en disant quel fichier less a utiliser et quel fichier css à générer.

    Puis le script génère le fichier à la volée à chaque chargement de page.

Leave a Reply

Your email address will not be published. Required fields are marked *

Mesure anti-spam. Merci de copier le code « aejvNS » dans le champ ci-dessous :