• fluid

    « Fluid Grids »,
    par Ethan Marcotte

    En fin de compte, c'est une simple question de contexte.

    Traduction par Magalie Cadiou,
    avec l'aimable permission d'A List Apart et de l'auteur Ethan Marcotte.
    Révision par Caroline Comacle et Philippe Michou.
    Publié originalement le 3 mars 2009 sur A List Apart.

    Les Grilles Fluides
    par ETHAN MARCOTTE


    Au début de l’année dernière, j’ai travaillé sur la refonte d’un site plutôt riche en contenu. Le client a donné peu de consignes : il fallait conserver le logo de l’organisme, déjà présent sur le site, améliorer la typographie et la lisibilité. Au début du processus, nous avons donc passé beaucoup de temps à concevoir une grille bien organisée pour accueillir les différents modules du contenu.

    Cette façon de penser est devenue plus commune ces dernières années. Les travaux de Mark Boulton et Khoi Vinh, entre autres, ont suscité un regain d’intérêt pour les grilles typographiques et leur utilisation en conception de sites Web. C’était l’idée du siècle : un million de Frameworks CSS et divers outils pour les compléter ont vu le jour, tous conçus pour permettre au concepteur moyen d’utiliser les grilles encore plus simplement. Pourquoi pas ? Après quelques instants de réflexion “grillesque”, les avantages paraissent évidents : les développeurs peuvent organiser leur contenu grâce à un Framework rationnel et structuré, et les utilisateurs peuvent consulter des sites organisés et lisibles.

    Mais notre client avait une dernière requête, et pas des moindres : la mise en page devait être fluide et s’adapter à la taille de la fenêtre du navigateur. En temps normal, j’aurai exprimé ma joie de façon bruyante et embarrassante. Les mises en page fluides ne sont pas assez utilisées en Web design, alors qu’elles offrent une liberté absolue aux utilisateurs et leur permettent de conserver leurs habitudes de navigation. Elles laissent également libre cours à l’imagination des concepteurs.

    La résolution d’écran minimale : un pieux mensonge

    Alors que nous pourrions profiter des avantages du Web design flexible, nous basons nos créations sur un petit mensonge : « la résolution d’écran minimale ». Le pouvoir magique que possèdent ces trois petits mots nous entraîne à multiplier les mises en page fixes, les retravaillant de temps en temps pour « optimiser » la largeur, après nous être assuré que cela ne poserait pas de problème. « La résolution d’écran minimale » nous permet de concevoir des sites pour un ensemble d’utilisateurs stéréotypés qui voient nos mises en page comme Dieu et Photoshop les ont faites. Ces utilisateurs naviguent toujours en plein écran dans une fenêtre 1024×768, et ne consultent jamais de sites Web, par exemple, à partir d’un OLPC laptop ou sur un écran vieux de quatre ans. Si la configuration d’un utilisateur ne correspond pas à la « résolution d’écran minimale », alors il n’a plus qu’à utiliser la barre de défilement horizontal, c’est ça ?

    Bien entendu, lorsque j’ai créé le site, je ne me suis pas payé le luxe de rédiger une diatribe sur le design fixe. À la place, je me suis heurté à la triste réalité : alors que nous avions conçu une grille plutôt complexe qui convenait au contenu à traiter, le client (et par extension, ses utilisateurs) nous demandait une mise en page fluide. Puisqu’à cette période tous les designs à base de grilles que j’ai pu trouver étaient de largeur fixe, je me suis retrouvé face à cette question : comment créer une grille fluide ?

    En fin de compte, c’est une simple question de contexte.

    Dois-je vraiment remercier Internet Explorer pour ça ?

    Face à ce problème insurmontable, j’ai fait ce que je savais faire de mieux : j’ai évité la difficulté. J’ai mis de côté pour un temps la conception d’une grille qui pourrait s’adapter à une mise en page non fixe, et je me suis concentré sur ce que je savais faire : j’ai défini les propriétés des couleurs et des arrière-plans, ainsi que les styles typographiques.

    Vous avez probablement entendu parler du fameux problème de redimensionnement des polices dont la taille est définie en pixels dans Internet Explorer (bug ou choix ?). Si vous codez un paragraphe en Georgia 16px et que l’utilisateur essaie d’augmenter ou de diminuer la taille du texte dans IE, il restera en 16px. Il est possible de redimensionner une page entière avec IE7 et les versions ultérieures, mais le redimensionnement du texte dont la taille est définie en pixels est toujours largement verboten dans Internet Explorer. Alors, pour apporter aux utilisateurs une flexibilité optimale, nous, les designers malins, laissons les pixels de côté et utilisons les unités relatives pour définir la taille des polices : les mots-clés, les pourcentages, ou mon préféré, les ems.

    Si vous avez déjà utilisé des unités relatives comme les ems, vous savez que tout est question de contexte : en d’autres mots, la taille réelle d’un élément défini en em est calculée selon la valeur font-size de son élément parent. Par exemple, nous travaillons sur ce design :

    C’est un exemple de texte basique dont la taille de police est définie en pixels.

    Rien de bien fou : quelques paragraphes en Helvetica 16px, une liste désordonnée dont la police a été réduite à 14px, et un titre h1 en haut, en Georgia 24px. Sexy, hein ?

    Ce qui est encore plus sexy, c’est qu’une seule règle nous permet d’organiser tout ça :

    Si la valeur font-size est de 100%, tous les éléments de la page sont affichés en fonction de la taille par défaut du navigateur, en général 16px. Et grâce à la feuille de style du navigateur, le titre h1 est gros, gras, et beau. Mais il est toujours en Helvetica, et prend bien trop de place. Il serait facile de régler ce problème de titre en Helvetica en ajoutant une valeur font-family, mais comment afficher le texte en 24px ? Ou diminuer de façon précise la taille de cette liste ?

    Les ems sont la solution. On prend la valeur voulue pour la propriété font-size de chaque élément en pixels, et on la divise par la valeur font-size de son conteneur (c’est-à-dire le contexte). Nous trouvons ainsi la valeur font-size voulue, exprimée en gentilles unités relatives em. En résumé :

    taille voulue ÷ taille du contexte = résultat

    Si on suppose que la taille de la typographie par défaut de la balise body est de 16px, nous pouvons utiliser cette formule pour n’importe quelle taille de police voulue. Pour adapter notre titre à la composition, nous divisons la taille voulue (24px) par la valeur font-size de son conteneur (16px) :

    24 ÷ 16 = 1.5

    Le titre fait donc 1,5 fois la taille par défaut du conteneur, soit 1,5em, valeur que nous pouvons intégrer directement à notre feuille de style.

    Pour la liste, il faut trouver l’équivalent en em de 14px. Nous pouvons utiliser la même formule. En supposant une fois de plus que la valeur font-size du body est définie à environ 16px, nous divisons simplement la taille voulue par celle du contexte :

    14 ÷ 16 = 0.875

    Nous trouvons donc la valeur de 0,875em, que nous intégrons à nouveau à notre CSS.

    Grâce à ces deux règles, notre page test est mieux organisée, et atteindra presque la perfection “pixellesque” après un petit nettoyage. Tout ça grâce à notre formule :

    valeur voulue ÷ contexte = résultat.

    Après quelques heures de nettoyage des styles de texte pour notre client, j’ai réalisé que j’avais trouvé la solution. Si nous pouvions définir les tailles de police comme des proportions mesurées en fonction du conteneur, alors nous pourrions faire la même chose avec les différents éléments présents dans notre grille.

    Après tout, on ne cherche pas « le pixel d’or » !

    Comme précédemment, commençons par une mise en page pas très excitante assez simple :

    Notre mise en page de base.

    Notre « design » est plutôt modeste. Mais ces styles simples sont intégrés à une grille bien organisée : sept colonnes de 124 px chacune, séparées par des espaces de 20 px, pour une largeur totale de 988 px. Mais oublions un peu ces vilains pixels. Les proportions sont notre nouvelle star, pas vrai ? Fluidifions tout ça, baby.

    Notre page de base, avec la grille superposée.

    Pour commencer, faisons comme si nous travaillions sur n’importe quelle mise en page, qu’elle soit fixe ou fluide : avant de commencer à coder, observons le design et évaluons
    les différentes zones de contenu. Heureusement la liste est assez restreinte.

    Les différentes zones de contenu.

    Nous avons le titre, une zone de contenu qui s’étend sur six colonnes, et une zone d’information contextuelle dans la colonne la plus à gauche. À partir de ce diagramme, nous pouvons discerner les balises qui entrent dans notre liste de contenu, au niveau structurel et sémantique.

    En appliquant quelques règles au texte, nous obtenons un bon point de départ visuel. Cependant, puisque le conteneur #page ne lui impose aucune contrainte, notre contenu sera redistribué pour correspondre à la largeur de la fenêtre du navigateur. Essayons de déchiffrer ces lignes de code :

    Nous avons utilisé des marges et des espacements pour aérer un peu notre design, et nous l’avons éloigné des bords de la fenêtre par un espace. Mais à la dernière ligne, nous utilisons une variante de notre formule font-size pour définir la largeur maximale de notre design. En divisant la largeur de notre composition de 988px par notre font-size de base de 16px, nous pouvons définir une valeur max-width en ems, qui correspond approximativement à la largeur en pixels de notre modèle, ce qui évitera à la page de dépasser notre largeur idéale de 988px. Mais puisque nous avons utilisé des ems pour définir cette limite, la valeur max-width augmentera quand l’utilisateur agrandira la taille du texte dans son navigateur. Un petit tour de passe-passe qui fonctionne même avec les versions plus anciennes d’Internet Explorer si un petit patch CSS est utilisé.

    Maintenant que notre design est correctement isolé, nous allons travailler chaque élément de contenu de notre inventaire, en commençant par le titre. Dans notre page, il s’étend sur cinq colonnes et leurs quatre espaces, sur une largeur totale de 700px. Il est séparé du bord gauche par une paire colonne/espace, ainsi décalé de144px. Si nous travaillions sur un design à largeur fixe, la tâche serait assez simple :

    Puisque nous travaillons dans un contexte fluide, les mesures fixes ne sont pas vraiment adaptées. Alors que je travaillais sur les tailles de police, je me suis rendu compte que chaque partie de la grille (ainsi que les éléments qu’elle contient) peut être exprimée en proportions relatives au conteneur. Autrement dit, comme lors de l’exercice de redimensionnement de police, nous ne nous concentrons pas uniquement sur la taille voulue mais aussi sur la relation entre cette taille et le conteneur de l’élément. Cela nous permettra de convertir les valeurs en pixels de notre design en pourcentages, et de garder les proportions de notre grille intactes lors de redimensionnements.

    En bref, nous obtiendrons une grille fluide.

    La mode est un éternel recommencement

    Par où commencer ?

    taille voulue ÷ contexte = résultat

    C’est vrai ! Notre fidèle formule est de retour. Nous pouvons utiliser la même analyse proportionnelle pour passer des largeurs de colonnes en pixels à des valeurs flexibles en pourcentages. Nous voulons donc une largeur de 700px pour le titre de la page, mais il est contenu dans un élément large de 988px.

    Convertissons la taille en pixels de notre titre en pourcentages.

    Il suffit de diviser 700px (la taille voulue) par 988px (le contexte) :

    700 ÷ 988 = 0.7085

    Et voilà le résultat : 0,7085 devient 70,85 %, une propriété width que nous pouvons tout de suite intégrer à notre feuille de style :

    Pouvons-nous procéder de la même façon pour notre marge de 144px? Comme j’aime ces questions pertinentes :

    144 ÷ 988 = 0.14575

    Une fois de plus, nous prenons le résultat 0.14575, soit 14.575%, et l’ajoutons à notre feuille de style comme valeur de la propriété margin-left du titre :

    Et voilà. En définissant la largeur et la marge du titre par rapport à leur conteneur, nous avons réussi à intégrer les mesures de notre grille en pourcentages dans le CSS. Les proportions du titre ne changeront pas, même lors de redimensionnements de la fenêtre du navigateur.

    Cette division peut être utilisée pour convertir la largeur de la zone d’écriture de 844px, avec sa marge de 124px sur la gauche. Pour cette zone :

    844 ÷ 988 = 0.85425

    Et pour la colonne d’information :

    124 ÷ 988 = 0.12551

    Ces deux divisions nous donnent des pourcentages que nous pouvons inclure dans notre feuille de style, améliorant encore notre mise en page.

    Notre grille fluide se précise encore.

    Changement de contexte

    Nous nous sommes concentrés jusqu’à maintenant sur les zones générales de contenu, nous n’avons pas encore travaillé les zones internes. À présent, le texte et ses informations contextuelles occupent toute la largeur de la zone et sont superposés. Mais dans notre composition initiale, cette zone ne s’étendait que sur cinq colonnes, et les informations afférentes se trouvaient dans la colonne la plus à droite.

    Les lecteurs les plus attentifs auront remarqué que dans notre mise en page actuelle, la zone de texte et la zone de titre ont la même largeur (700px), et qu’il en est de même pour la marge et la colonne de gauche que nous avons étudiées tout à l’heure (124px). Nous avons déjà calculé ces mesures, mais nous ne pouvons pas réutiliser la formule : le contexte n’est plus le même.

    Puisque nous travaillons avec un nouveau conteneur, nous devons utiliser sa largeur pour le contexte.

    Jusqu’ici, nous calculions des pourcentages en fonction de la largeur de #page (988px).Nous travaillons maintenant avec .entry et .content, qui ont des mesures inférieures. Nous devons donc définir un nouveau contexte, et utiliser les valeurs .entry et .content comme références. Pour trouver la largeur en pourcentages du bloc principal, nous prenons sa largeur d’origine de 700px, que nous divisons par 844px :

    700 ÷ 844 = 0.82938

    Nous pouvons utiliser les mêmes repères pour notre colonne 124px sur la droite :

    124 ÷ 844 = 0.14692

    Intégrons maintenant ces mesures à notre CSS :

    Notre travail est maintenant terminé, notre grille fluide est finalisée.

    Les arrondis

    Les patchs CSS ne sont pas présents dans ma démonstration : j’ai rencontré très peu de problèmes de compatibilité avec les navigateurs. Je vous conseille l’excellent article de John Resig, Sub-Pixel Problems in CSS. Il explique comment sont traitées les largeurs en pourcentages par différents navigateurs, et le processus par lequel ils gèrent les sous-pixels.

    omme le dit John dans son article, si on veut afficher quatre éléments de 25 % de largeur dans un conteneur de 50px large, les navigateurs récents ne peuvent afficher les éléments à 12.5px. Ils vont, pour la plupart, arrondir la taille des colonnes pour qu’elles s’intègrent au mieux dans la mise en page. Par exemple, Internet Explorer arrondit simplement ces valeurs au chiffre supérieur, désorganisant la mise en page.

    Si votre mise en page comporte des marges importantes, cela ne devrait pas vous poser problème. Pour pallier cette réorganisation malvenue de nos colonnes exprimées en pourcentages dans Internet explorer, nous pouvons réduire leur valeur cible d’un pixel. Prenons l’exemple d’une marge gauche trop large pour IE. Nous pourrions modifier notre calcul de cette façon :

    124 ÷ 988 = 0.12551

    Nous prenons la valeur inférieure 123px :

    123 ÷ 988 = 0.12449

    Nos problèmes de mise en page devraient disparaître en intégrant cette propriété width de 12,449 % dans notre feuille de style IE.

    Une grille pour chaque saison

    Ce que vous venez de lire n’est qu’un point de départ : nous avons de nombreux problèmes à résoudre. Ils apparaissent pour la plupart en présence d’un contenu fixe (comme les images, un contenu Flash etc.) dans un Framework fluide. J’ai testé plusieurs solutions sur mon blog, mais on en trouve des meilleures un peu partout.

    Pour terminer, qu’il soit fixe ou fluide, le design reste une tâche complexe. Compte tenu de nos accomplissements ces dernières années (abandon des tableaux archaïques, promotion de l’utilisation de standards au sein des entreprises, plaidoyers en faveur de standards plus élevés pour nos navigateurs et nos utilisateurs), j’espère que nous pourrons mettre fin au règne de cette « résolution d’écran minimale ». Après tout, nos utilisateurs ne se servent pas de leurs navigateurs de façon aussi fixe que nos mises en page pourraient le laisser croire. J’espère que cet aperçu des grilles fluides vous a donné des idées, et j’ai hâte de voir ce que vous êtes capables d’en faire. Nos utilisateurs aussi !

    Lectures complémentaires

    Comme vous avez pu le comprendre lors de ma discrète harangue petite digression introductive, deux de mes passions sont le Web design fluide et, depuis peu, la conception de grilles. Ces sujets sont traités, entre autres, dans les documents suivants :

    Pour terminer, lors d’une conférence sur la conception des grilles fluides que j’ai donnée en août, quelqu’un a évoqué Fluid 960 Grid System. Si vous utilisez déjà un Framework CSS prédéfini comme un framework 960, le transposer en grille fluide peut être intéressant pour vous.


    10 Responses to “« Fluid Grids »,
    par Ethan Marcotte”

    1. Johan Puisais

      Bravo et grand merci pour cette traduction, c’est en effet un très bon article. Mon prochain template sera certainement fluide… suité à ces éclaircissements lumineux.

      Répondre
    2. Jonathan, Webdesigner

      Encore un très bon article, merci pour la traduction.

      Vous pouvez fixer la valeur “font-size” du body à .76em pour régler une taille standard des polices, environ celle du menu du navigateur (fichier, édition, etc).
      Une bonne pratique serait de spécifier les dimensions des hauteurs en “em” et celles des largeurs en “pourcentage”, avec un min-width en “em”.

      Répondre

    Leave a Reply

    XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>