Lâchez prise sans perdre le contrôle grâce à l’unité CSS em

Cela fait déjà bien longtemps qu’il est recommandé d’utiliser des unités relatives pour définir les tailles de texte, avec une préférence pour em plutôt que %. « A DAO Of Web Design » 1, écrit en 2000 par John Allsopp, est un article fondateur de l’intégration Web de qualité :

C’est la nature du web d’être flexible, et il en va de notre rôle en tant que concepteurs et développeurs d’embrasser cette flexibilité et de produire des pages qui, en étant flexible, sont accessibles à tous. Faire des pages qui s’adaptent aux besoins d’un lecteur, dont la vue est plus qu’imparfaite, et qui souhaitent lire des pages avec une grande taille de police.

Ces principes sont tellement essentiels qu’ils font parti des critères d’accessibilité du W3C 2 et de leur déclinaison française AccessiWeb 3, et assez naturellement des Bonnes Pratiques qualité d’Opquast 4.

La volonté très — trop — courante de maîtriser complètement la façon dont les contenus s’affichent sur les écrans, à tel point qu’on parle de « Pixel Perfect », va complètement à l’encontre de cette diversité de supports et de préférences des utilisateurs.

Aujourd’hui, je parcours le Web principalement sur un ordinateur, mais aussi de plus en plus souvent sur un smartphone, occasionnellement sur une tablette, parfois sur un ordinateur connecté à une télévision, mais par contre plutôt rarement sur une liseuse. Je ne suis pas une exception, ces nouveaux modes de navigation sur le Web sont de plus en plus largement utilisés 5 et de plus en plus nombreux et variés. Vous pouvez au moins ajouter à ma liste les consoles de jeux de salon et portables 6, les boitiers d’accès Internet, les télévisions connectées, les lunettes et les montres.

Nous ne savons de plus pas de quoi sera fait le futur du Web, donc il est important de s’attacher à accepter que les contextes de navigation changent, et faire en sorte que les dégâts sur nos réalisations soient les plus faibles possibles. C’est le principe « Future Friendly » que nous devons embrasser.

Les interfaces doivent être adaptées à des conditions de consultations variables

Les nouveaux moyens de navigation sur le Web doivent donc être pris en compte dans la conception des sites. Ces différents appareils ont bien entendu des tailles physiques et formats — paysage ou portrait notamment — très différents. Nous les utilisons aussi à des distances différentes, et avec des moyens d’interaction très variables, de la souris à la gestuelle en passant par le tactile, la voix, une télécommande ou manette de jeux, etc. Mais un sujet à la fois, concentrons nous ici sur l’affichage.

La diversité de tailles et distances de visualisation des écrans impose de concevoir la présentation afin que celle-ci soit pertinente de base pour un maximum d’utilisateurs, mais aussi adaptable aux préférences ou nécessités éventuelles de certains d’entre eux.

Il existe pour cela plusieurs techniques, parfois complémentaires.

Le pixel de référence

Avant, un pixel était un pixel physique, et même si la densité de pixels physiques variait déjà pas mal, une dimensions exprimée en pixel était appliquée directement sur de « vrais » pixels.

Afin de retrouver des mesures cohérentes d’un appareil à un autre, le W3C a donné une nouvelle définition au pixel CSS, appelé maintenant pixel de référence.

Ainsi, si l’on s’intéresse à la taille réelle d’un bloc de 10 lignes de texte avec une font-size de 16px et une line-height de 1.5 — soit une hauteur de 240 pixels —, la dimension physique verticale devra être de l’ordre de quatre centimètres et demi à une distance de visualisation de cinquante centimètres — un ordinateur ou une tablette par exemple :

Taille physique nécessaire pour visualiser 10 lignes de texte à 50cm de distance
Taille physique nécessaire pour visualiser 10 lignes de texte à 50cm de distance

Elle devra être de l’ordre de trente six centimètres à une distance de visualisation de quatre mètres — une télévision à priori :

Taille physique nécessaire pour visualiser ces mêmes 10 lignes de texte à 4m de distance
Taille physique nécessaire pour visualiser ces mêmes 10 lignes de texte à 4m de distance

Malheureusement, tous les fabricants ne respectent pas cette définition du pixel de référence, et on se retrouve avec des variations assez importantes qui pénalisent les utilisateurs, et peuvent nécessiter des adaptations spécifiques.

Le viewport

Pour permettre un affichage confortable sur ses écrans « Retina » — ou HiDPI — à forte densité de pixels tant de sites prévus pour mobiles que de sites à grande largeur, Apple a inventé la balise <meta name=”viewport”>, une dimension virtuelle supplémentaire permettant d’ajuster la taille des pixels CSS. Avec ce viewport associé à une dimension virtuelle device-width 7, le pixel CSS doit rester de taille relativement constante d’un appareil à l’autre à distance de vision similaire, quelle que soit la densité de pixels réels, c’est à dire proche du pixel de référence.

Cependant, afin de permettre l’affichage des nombreux sites non adaptés aux mobiles, les smartphones utilisent souvent un viewport par défaut très grand, bien plus que celui donnant des pixels CSS à la taille de référence. Par exemple, le viewport par défaut de l’iPhone 4, premier smartphone HiDPI avec 640 pixels physiques en largeur, est de 980 pixels. Le viewport optimal sur mobile — défini principalement avec width=device-width — est par contre de 320 pixels. 8

Apple a aussi inventé la propriété CSS device-pixel-ratio pour indiquer le rapport entre les pixels CSS et pixels réels, propriété remplacée depuis par l’unité standard dppx 9. Les premiers appareils HiDPI avaient quatre fois plus de pixels réels que de pixels CSS — soit 2dppx — mais le marché s’est énormément diversifié.

De même, de nombreuses télévisions connectées et consoles de jeu de salon ont un viewport inférieur à leur résolution native Full HD — 1920×1080 pixels — afin de permettre une bonne lisibilité à grande distance. Mais certaines conservent le viewport natif 10.

Les viewports de certaines consoles de salon et TV connectées
Les viewports de certaines consoles de salon et TV connectées

Associé à ce viewport, on peut aujourd’hui mettre en place des présentations adaptatives des contenus à l’aide de Media Queries CSS 11.

Malheureusement, même un viewport adapté ne suffit pas forcément pour indiquer à un site comment proposer une présentation optimisée.

De plus, le viewport est défini par le constructeur, est donc le même pour tous les utilisateurs d’un même matériel, alors que leurs besoins ne sont pas les mêmes.

Le zoom

Une autre façon d’adapter la présentation à une forte densité de pixels ou une grande distance de consultation, en conservant une taille de pixel CSS plus petite, égale ou proche de sa taille réelle, est de grossir les éléments eux-mêmes.

Une étude faite par Facebook 12 montre que 15% de ses visiteurs ont un niveau de zoom différent de 100%. Même s’il est probable qu’une partie de ces zooms sont involontaires 13, surtout les 5% réduisant la taille, il y a probablement une partie des 10% agrandissant la taille qui sont volontaires. Malheureusement, l’étude ne dit pas s’il s’agit du zoom global ou du zoom texte. Étant donnée la configuration par défaut de la plupart des navigateurs de nos jours, c’est probablement le zoom global.

Le zoom global

Un moyen simple de grossir les éléments de l’interface sans aucun travail spécifique est tout simplement de laisser l’utilisateur le faire lui-même en autorisant le zoom global 14.

Ce zoom global est disponible sur tous les navigateurs depuis Opera 2.10 en 1996, puis surtout Internet Explorer 7 en 2006 15. Il est indispensable sur smartphones et tablettes pour consulter les sites qui ne proposent ni adaptation automatique en RWD ni version dédiée mobile. Une fonction de loupe/zoom global est aussi disponible dans les systèmes d’exploitation depuis longtemps.

Sur petits écrans, ce zoom permet de consulter les sites non adaptatifs en focalisant la lecture sur une zone particulière de la page. Il est d’ailleurs facilité par des manipulations tactiles simples inventées pour l’occasion. Un double tap — s’il est bien géré — permet d’accéder rapidement au niveau de zoom exactement adapté à l’élément concerné, ou revenir en plein écran.

Illustration du double tap
Illustration du double tap issue du site androidpatterns.com

Sur plus grands écrans, le zoom global s’effectue en général à l’aide d’une combinaison de touches, d’une touche et du scroll souris ou trackpad, voire d’un menu.

Un défaut du zoom global est que sur la plupart des sites, visités dans une fenêtre de navigateur de taille raisonnable — je ne parle donc pas ici des navigateurs mis en plein écran sur un 27 pouces de résolution gigantesque —, le site dépasse vite du navigateur en largeur, nécessitant un mélange de scroll vertical et horizontal pour naviguer. Si cela est encore accepté sur mobile pour les sites non adaptés, cela est très peu satisfaisant sur ordinateur.

Heureusement, le zoom global sur ordinateur prend aujourd’hui en compte les Media Queries du Responsive Web Design, simulant une diminution du viewport. Par contre, ce n’est pas le cas du zoom global tactile — double tap ou pinch to zoom — sur smartphones et tablettes 16.

Malheureusement, peu de sites ont déjà évolué vers le Responsive Web Design, continuent à utiliser des tailles de texte ridicules, et débordent vite de l’écran quand on fait un zoom global pour améliorer la lisibilité. Le zoom global n’est donc pas encore la solution parfaite à ce niveau là.

Un autre défaut du zoom global est l’altération de la qualité de rendu des éléments graphiques de type bitmap. Le navigateur doit créer des pixels inexistants dans la source pour afficher une image dans une dimension supérieure à celle native, et la plupart des algorithmes de ce type conduisent à un rendu paraissant flou.

Illustration de l'effet flou du zoom d'images bitmap
Illustration de l’effet flou du zoom d’images bitmap

L’effet est bien entendu proportionnel au niveau de zoom utilisé, mais les personnes ayant besoin de zoomer régulièrement de façon importante peuvent être gênées par ce rendu. Avec l’arrivée des écrans Retina, l’utilisation d’images de plus grandes dimensions que leur zone d’affichage permet aussi de réduire cet effet partiellement. Utiliser des images vectorielles permet par contre d’annuler complètement ce défaut, mais tout n’est pas faisable en vectoriel.

Le zoom texte, zoom historique

Le plus ancien zoom disponible dans les navigateurs est le zoom texte. Il porte un peu mal son nom, puisque qu’il ne permettait pas initialement de grossir les textes définis en tailles absolues — px, pt, etc. — mais uniquement ceux définis en tailles relatives — em, %, ex, etc.

Aujourd’hui, le zoom texte permet effectivement d’agrandir tous les textes, quelle que soit l’unité définissant leur taille, dans tous les navigateurs qui le proposent 17, sauf Internet Explorer, qui persiste encore dans sa version 10 18, à bloquer les tailles définies en pixels.

Une étude menée en mai 2012 par WebAIM montre que 8% des utilisateurs de lecteurs d’écran interrogés utilisent le zoom texte du navigateur. Une population certes réduite 19, mais qu’il ne faut pas négliger.

L’utilisation d’unités relatives, pour les tailles de texte au moins, est donc toujours une bonne pratique d’actualité.

Une faiblesse du zoom texte, en supposant que les sites soient bien intégrés en unités relatives, reste que celui-ci doit être défini site par site. Il faut donc s’intéresser aux paramétrages du navigateur pour définir une taille de texte par défaut valable sur tous les sites. 20

La définition de la taille de texte par défaut

Ces paramétrages sont simples sur tous les navigateurs, les voilà sur Firefox et Chrome par exemple :

Configuration de la taille de texte par défaut dans Firefox en pixels
Configuration de la taille de texte par défaut dans Firefox en pixels
Configuration de la taille de texte par défaut dans Chrome
Configuration de la taille de texte par défaut dans Chrome, sans valeur exacte visible, ce qui n’est pas plus mal pour la plupart des utilisateurs

La diversité de tailles et distances de visualisation des écrans que j’utilise m’a ainsi par exemple poussé à configurer certains de mes navigateurs avec des tailles de texte par défaut différentes de 16px. Sur mes ordinateurs portables, professionnel et personnel, qui ont tous les deux une assez forte densité de pixels, sans pour autant être HiDPI, je suis passé à 18px. Faible différence vous me direz, mais le gain en confort de lecture est immédiat. Sur ma télévision, ou plutôt sur l’ordinateur branché dessus avec une résolution native Full HD, je suis passé à 24px, la distance de visualisation d’environ quatre mètres associée à une taille d’écran de 128 centimètres — 52 pouces — de diagonale rendant le texte illisible en taille par défaut.

Sur les sites qui prennent en compte ces préférences de leurs visiteurs, tout se passe bien, je lis plus facilement les contenus, le site gagne des points dans l’avis que je m’en fais 21.

Mais pas de miracle, définir une taille de texte par défaut différente de 16px dans un navigateur ne change toujours rien aux textes dont la taille est définie en tailles absolues, quel que soit le navigateur. Sur ces sites qui ignorent — ou savent mais décident délibérément d’oublier — que ces réglages sont possibles, les effets de bord vont de l’anecdotique au critique, souvent selon le facteur de grossissement appliqué par rapport aux 16px les plus courants, mais pas uniquement.

Sur cDiscount 22, l’un des principaux sites e‑commerce en France, le simple passage de 16px à 18px a un effet désastreux, cette simple augmentation de deux pixels de la taille du texte fait disparaître le contenu le plus important de la page. :

Une page produit sur cDiscount
Une page produit sur cDiscount avec une taille de texte de 18px

Ce contenu ne disparaît en fait pas vraiment, mais est déplacé en dessous du menu de navigation de gauche, qui est plutôt long :

La zone de contenu principal déplacée sous la navigation
La zone de contenu principal déplacée sous la navigation sur cDiscount avec une taille de texte de 18px

L’affichage réagit au changement de taille de texte, donc au moins une partie de ces éléments ont des dimensions définies en unités relatives, mais le travail n’a pas été fait complètement. Dans ce cas précis, tout fixer en px ne serait pas réellement satisfaisant, mais aurait au moins le mérite de ne pas tout casser en cas de taille de texte différente de 16px.

La taille par défaut de 16px n’est pas un standard

De fait, on trouve la plupart du temps une taille par défaut de 16px dans les navigateurs d’ordinateurs, smartphones ou tablettes. Mais il est important de savoir qu’au delà du fait que certains utilisateurs changent cette valeur par choix, certains appareil et/ou navigateurs sont fournis avec une taille par défaut différente.

Sur ma liseuse Cybook Odyssey par exemple, c’est le constructeur Bookeen qui a lui-même fait le choix de définir une taille de texte par défaut à 21px. C’est le cas de plusieurs constructeurs, notamment Amazon sur certains Kindle.

A l’inverse, certains navigateurs sont configurés avec une taille de texte par défaut inférieure à 16px.

J’ai développé un tout petit outil en ligne pour déterminer la taille de texte par défaut d’un navigateur :

Testez votre taille de texte par défaut avec http://lab.gasteroprod.com/rfs/
Testez votre taille de texte par défaut avec http://lab.gasteroprod.com/rfs/

Les données sont collectées via Browserscope, ce qui m’a permis de découvrir des valeurs atypiques :

Navigateur Taille de base
Opera Mini 4.5 13
Palm webOS 2.0 & webOS TouchPad 14
Opera Mini 7 17
AOL 9 20
Cybook Odyssey 21
Blackberry 6.0 22
NetFront NX 23
Kindle 3 26

Pour continuer à compliquer la situation, il peut être utile de savoir que sur mobiles certains navigateurs peuvent prendre l’initiative de grossir eux-mêmes une partie des textes d’une page, afin d’en améliorer la lisibilité. La propriété css-size-adjust en cours d’élaboration au W3C permet de contrôler ce comportement.

La dimension des textes n’est donc vraiment que difficilement contrôlable, au grand dam des adeptes du pixel perfect.

Et pour les sites qui utilisent des tailles minuscules en px ?

Malheureusement, une grande quantité de sites utilisent des tailles de texte en px, et encore pire, avec des valeurs délirantes de 10px ou 11px.

C’est le cas du site Arrêt sur Images qui force une taille de 11px sur certains textes :

La page d'accueil de Arrêt sur Image, illisible
La page d’accueil de Arrêt sur Image, illisible

Modifier ma taille de texte par défaut ne suffit alors pas, puisque celle-ci n’est pas respectée si les tailles sont définies en px. Heureusement, pour ces cas extrêmes il est possible de forcer une taille minimale dans les préférences des navigateurs, comme ici dans Firefox et Chrome :

Réglage de la taille minimale de texte dans Firefox
Réglage de la taille minimale de texte dans Firefox
Réglage de la taille minimale de texte dans Chrome
Réglage de la taille minimale de texte dans Chrome

L’effet a bien entendu plus d’impact que celui de la taille par défaut ou du zoom texte, et en a même potentiellement sur les sites utilisant des tailles de texte proportionnelles, car les textes trop petits sont grossis alors que ceux de taille suffisante ne le sont pas.

L’effet sur Arrêt sur Images est effectivement désastreux, de nombreux textes sortants de leur conteneur — qui n’en est donc pas vraiment un — ou se superposants :

La page d'accueil d'Arrêt sur Images
La page d’accueil d’Arrêt sur Images encore plus inexploitable avec une taille de texte forcée à 14px au minimum

L’effet est désastreux parce que le site force l’utilisateur à employer les grands moyens, plutôt que simplement respecter ses préférences.

Tout ceci ne se produirait pas si des tailles proportionnelles étaient utilisées pour le texte, et si les conteneurs s’adaptaient à leurs contenus.

Des em pour toutes les tailles verticales…

Afin qu’un site puisse s’adapter sans problème à des tailles relatives de texte, il est impératif que les dimensions verticales au moins soient elles aussi relatives. Les blocs peuvent bien entendu s’adapter automatiquement à leurs contenus, mais cela ne suffit pas. Il est nécessaire de préciser les dimensions verticales de certains éléments, en utilisant les mêmes unités relatives afin de conserver un bon rythme vertical dans la macro typographie des pages.

Comme le dit Chris Armstrong dans « The Infinite Grid » 23, « avec les pixels et autres unités absolues, une mise en page ne fonctionne que dans certaines situations précises : ces unités imposent donc une sorte de date de péremption. Les unités proportionnelles (em, rem et pourcentages) vous permettent de définir les relations importantes entre les éléments, et sont un premier pas indispensable pour aboutir à une grille indépendante des dimensions du navigateur. »

…mais aussi pour les tailles horizontales

Ainsi, il est intéressant d’utiliser ces mêmes unités relatives — à la taille de texte, donc plutôt em ou rem que % — pour définir les largeurs de blocs, notamment de paragraphes 24.

Cela permet d’assurer une présentation optimale du texte, notamment en conservant un nombre optimal de caractères par ligne — de 55 à 65, à affiner selon les langues concernées — quelle que soit la taille du texte. Pour cela, une largeur de 30em est une valeur courante, à ajuster évidemment selon la nature de la police de caractères. 25

Comment gérer les valeurs en em ?

En 2004, Richard Rutter proposait de définir une font-size de 62,5% sur l’élément body afin de se placer sur une base 10px, en supposant que la taille par défaut du navigateur était de 16px. Cela permettait ainsi de définir facilement les tailles des éléments en em, en divisant par 10 la valeur souhaitée en pixels.

On pouvait ainsi écrire ce qui suit :

body { font-size: 62.5%; } 
h1 { font-size: 2.4em; } /*=24px */
h2 { font-size: 2.1em; } /*=21px */ 
p { font-size: 1.6em; } /*=16px*/

Malheureusement, définir ainsi une base à 10px impose de redéfinir toutes les tailles des éléments de la page, et le risque d’obtenir un jour des éléments à cette taille de 10px n’est pas négligeable. Laisser la taille par défaut du navigateur, ou la valeur choisie par l’utilisateur, comme valeur de base des tailles de texte semble bien évidemment plus prudent.

En 2007, ce même Richard Rutter proposa finalement de définir plutôt une font-size de base sur le body à 100%, conduisant ainsi à l’écriture suivante :

body { font-size: 100%; } 
h1 { font-size: 1.5em; } /*=24px */
h2 { font-size: 1.3125em; } /*=21px */ 
p { font-size: 1em; } /*=16px */

La CSS est ainsi bien sûr plus difficile à écrire, mais si c’était effectivement le cas en 2007, ce ne l’est plus vraiment en 2013 grâce aux préprocesseurs CSS tels que LESS, Sass ou Stylus.

Voici par exemple une méthode simple à exploiter en Sass :

$base-font-size: 16px;
@function em($target, $context: $base-font-size) {
	@if $target == 0 { @return 0 }
	@return $target / $context + 0em;
}
body { font-size: 100%; }
h1 { font-size: em(24px); } // 1.5em
h2 { font-size: em(21px); } // 1.3125em
p { font-size: em(16px); } // 1em
ul { font-size: em(14px); } // 0.875em
ul ul { font-size: em(14, 14px); } // 1em

D’autre part, les Media Queries ne tiennent pas compte de la définition de font-size du body, même si elles sont définies en em, donc elles ne sont plus cohérentes avec les contenus qu’elles tentent d’adapter au contexte. Avec un font-size : 62.5% sur le body, un élément dont on définirait la largeur à 50em serait moins large que le seuil de déclenchement d’une Media Query basée sur cette même valeur de 50em. La première valeur, à supposer que l’élément soit enfant direct du body, serait évaluée à 500px (50 fois 10) — avec une taille de base de 16px — alors que la Media Query serait évaluée à 800px (50 fois 16).

Au final, il semble recommandé, comme suggéré par le Filament Group dans « How we learned to leave default font-size alone and embrace the em », de ne pas toucher du tout à la taille de texte globale héritée de la configuration — par défaut ou personnalisée — du navigateur, et donc ne pas mettre de font-size sur le body.

Simplifions nous la vie avec rem… ou pas

L’unité rem, récente mais déjà plutôt bien supportée dans les navigateurs, permet de définir des tailles relatives comme em, mais en prenant la taille de html comme référence plutôt que l’élément parent.

rem permet donc d’éviter la dernière ligne du code ci-dessus, qui est nécessaire pour éviter que les listes imbriquées soient de plus en plus petites par récursivité. Avec rem, plus besoin de « trainer » le contexte systématiquement, cela évite certains maux de crâne.

Malheureusement, cette force est aussi une faiblesse potentielle.

Effectivement, définir certaines tailles par rapport à leur contexte à beaucoup plus de sens, notamment les espacements entre contenus — des titres et paragraphes par exemple — avec margin et padding.

De plus, si vous souhaitez modifier la taille d’un composant dans la page 26, vous devrez modifier la taille de tous ses éléments constituants, alors qu’en em vous pourriez modifier uniquement la taille de l’élément conteneur, comme démontré dans l’article « Sizing (Web) components » de simurai.

Dimensionnement simple d'un composant grâce aux em
Dimensionnement simple d’un composant grâce aux em

Si l’on ne tient pas compte du fait qu’il faut de plus prévoir des fallbacks en px — hum… — pour les vieux navigateurs 27, il pourra donc être tout de même intéressant d’utiliser des rem pour les éléments racine des composants, et des em pour leurs sous éléments. À condition d’être sûr de pouvoir identifier ces composants.

Tout n’est pas si simple

Que l’on utilise des em ou des rem, différentes problématiques peuvent complexifier la tâche.

Tout d’abord, il faut bien comprendre que de nombreuses conversions entre unités sont effectuées entre les px encore souvent utilisés dans la tête des graphistes 28 et les px utilisés au final par le moteur de rendu des navigateurs :

  • Application directe des px issus de la création graphique dans le code destiné au préprocesseur CSS, aucun problème ;
  • Conversion des px en em par le préprocesseur avec arrondi systématique 29, première source d’approximation ;
  • Calcul de la « vraie » dimension déclarée d’un élément à partir de sa taille définie en em et de sa cascade de contexte 30, seconde source d’approximation ;
  • Application de la taille par défaut du navigateur, qu’elle soit d’origine ou modifiée par l’utilisateur, si la dimension est en unité relative 31, troisième source d’approximation ;
  • Conversion de cette dimension en pixels CSS si l’unité est différente, quatrième source d’approximation ;
  • Conversion des pixels CSS en « vrais » pixels pour effectivement dessiner l’élément, cinquième source d’approximation.

Le cumul des conversions et arrondis éventuels peut conduire au final à des rendus erronés, ou tout du moins peu satisfaisants, que l’on soit ou non adepte du pixel perfect. Rassurez-vous, définir toutes les tailles en px ne règlera pas — pas complètement en tout cas — le problème, donc ce n’est pas un argument vraiment valide contre les unités relatives.

Une autre difficulté concerne les images. Celles qui sont en SVG, donc vectorielles, peuvent avoir sans problème des dimensions définies en valeurs relatives, et donc s’ajuster avec les tailles de texte. Celles qui sont en formats bitmap, par contre, supportent potentiellement assez mal les redimensionnements, comme cela a été évoqué au sujet du zoom global. Il faut donc décider si on applique tout de même des dimensions relatives afin de conserver des proportions constantes, ou si on conserve pour ces images leurs dimensions « réelles », en ajustant le positionnement des éléments qui les entourent ou voisinent. Le choix est relativement simple pour des illustrations flottant au sein d’un texte, bien moins pour des éléments d’interface. Privilégier SVG pour ces derniers est donc préférable.

Toujours concernant les images, un point particulier concerne la technique des sprites, pour laquelle la dimension et le positionnement de la zone utile doivent s’ajuster selon la dimension de son élément conteneur. Je vous invite à décortiquer les « mixins magiques » de Marie pour couvrir ce besoin.

La principale limite du design élastique est résolue par le Responsive Web Design

Une autre limite souvent citée pour refuser le design élastique — c’est à dire avec des largeurs de blocks définies en em — est qu’il fini par sortir du cadre du navigateur quand la taille de texte est agrandie.

Si cela était vrai il y a quelque temps, le Responsive Web Design permet aujourd’hui de gérer cela de manière plus que satisfaisante, comme le défend l’article « The EMs have it : Proportional Media Queries FTW ! » de Liza Gardner et l’illustre parfaitement la « Goldilocks Approach ».

Design élastique avec une taille de texte de base de 16px
Design élastique avec une taille de texte de base de 16px
Le même design élastique avec une taille de base de 20px
Le même design élastique avec une taille de base de 20px
Le même design élastique avec une taille de base de 24px déclenche une Media Query ajustant l'affichage à l'espace disponible
Le même design élastique avec une taille de base de 24px déclenche une Media Query ajustant l’affichage à l’espace disponible

Je pourrais écrire encore beaucoup au sujet du Responsive Web Design élastique, mais je crains de vous assommer définitivement. Des exemples à explorer pour se convaincre sont les sites de Marie Guillaumet 32, Smashing Magazine, Clearleft, ou celui de votre humble serviteur.

Ce qu’il faut retenir, c’est que vous n’avez pas le choix, qu’il faut lâcher prise…

Votre objectif est — devrait être — de diffuser un message, un service, et d’atteindre un public le plus large possible en lui proposant une expérience positive.

Respecter son public et s’adapter à ses préférences — tant que possible — est bien évidemment une bonne pratique.

…mais que cela ne nécessite pas de perdre le contrôle !

L’intégration en Responsive Web Design élastique est — aujourd’hui, à mon avis — le meilleur moyen de choisir vous-même comment votre site s’affiche, tout en respectant les préférences de vos visiteurs.

L’utilisateur peut choisir quelle est la taille le texte la plus confortable pour sa lecture, selon l’appareil qu’il utilise, et vous décidez comment votre site doit s’afficher avec ce paramétrage.

  1. Article traduit par les Pompeurs, bien entendu, sous le titre « Le tao du design Web ».
  2. Le critère 1.4.4 des WCAG 2.0 indique que « […] le texte peut être redimensionné jusqu’à 200% sans l’aide d’une technologie d’assistance et sans perte de contenu ou de fonctionnalité ». Les techniques de mise en œuvre associées indiquent clairement qu’il est nécessaire d’utiliser des dimensions en em.
  3. Le critère 10.4 du label AccessiWeb 2.2 demande « dans chaque page Web, le texte reste-t-il lisible lorsque la taille des caractères est augmentée jusqu’à 200%, au moins ? ».
  4. Le critère 142 de la liste Opquast v2 indique clairement que « la taille des polices destinées à l’affichage écran est exprimée en taille variable et non en taille fixe. »
  5. Plusieurs études, dont celle de comScore citée dans ces slides, indiquent que le temps passer à naviguer sur smartphones et tablettes a maintenant dépassé celui sur PC.
  6. Anna Debenham a montré dans sa conférence « Console Browsers : the ultimate torture test » à Mobilism 2013 que 20% des britanniques entre 16 et 34 ans naviguent sur le Web depuis leur console de jeu. Je vous invite à consulter ses slides et même à regarder la vidéo.
  7. C’est l’instruction <meta name=« viewport » content=« width=device-width, initial-scale=1.0 » /> à placer dans le <head> de vos pages.
  8. Je vous invite à lire l’article sur le viewport d’Alsacréations, très complet.
  9. Non, tout ceci n’est pas simple, mais c’est essentiel pour maîtriser l’intégration Web aujourd’hui. Vous avez le droit de prendre de l’aspirine après avoir lu la documentation de la résolution sur MDN.
  10. Je vous invite à consulter la présentation « Are you browsing confortably » de Steve Workman.
  11. C’est le Responsive Web Design formulé par Ethan Marcotte et ses évolutions ultérieures, dont le principe Mobile First formulé par Luke Wroblewski.
  12. Cette étude est citée en commentaire d’un message de Paul Irish sur Google+.
  13. Une combinaison de touches suffit à les déclencher.
  14. Oui, il est possible d’interdire le zoom, notamment sur smartphone, et certains cas sont pertinents. Mais trop de sites de purs contenus interdisent le zoom en dépit du bon sens.
  15. À noter, le zoom global implémenté dans IE7 était loin de faire l’unanimité, et induisait des bugs de rendu CSS non négligeables.
  16. J’avoue n’avoir pas eu entre les mains d’ordinateur avec écran tactile pour tester comment chaque navigateur se comporte lors du zoom tactile.
  17. Chrome ne le propose pas du tout, et les quelques extensions qui tentent de l’ajouter ne sont pas très ergonomiques ou efficaces.
  18. Limite constatée dans IE9 et IE10. Je n’ai pas eu l’occasion de vérifier dans IE11, mais j’ai peu d’espoir.
  19. D’autant plus que le zoom quel qu’il soit me paraît plus utile à ceux qui n’utilisent PAS de lecteur d’écran, c’est un peu confus comme étude.
  20. Chrome permet par contre de définir un niveau de zoom par défaut dans les paramètres, mais il s’agit du zoom global, pas du zoom texte.
  21. C’est bien entendu loin d’être aussi important que le contenu lui-même, mais ça compte pas mal, comme peut l’être la performance.
  22. Cette démonstration s’appuie sur des copies d’écran de sites divers et variés. Les erreurs relevées ne représentent en aucun cas des jugements de valeurs sur les sites concernés ou ceux qui les ont mis en œuvre, les contraintes projet m’étant inconnues.
  23. La citation traduite est extraite de la version française réalisée par les Pompeurs, « La grille infinie ».
  24. Voir « The Elements of Typographic Style Applied to the Web ».
  25. C’est un des nombreux enseignements de l’excellente conférence « La macro typographie de la page Web » animée par Anne-Sophie Fradier à Paris Web 2010.
  26. Ce que Brad Frost appelle des molécules dans « Atomic Design ».
  27. rem est supporté à partir de IE9, mais toujours pas dans Opera Mini.
  28. Certains web designers, surtout anglo-saxons, commencent à raisonner directement en em dans le navigateur, mais j’avoue que cela n’est pas simple et risque de brider la créativité visuelle.
  29. La précision de l’arrondi fait par le préprocesseur peut éventuellement être configurée, comme c’est le cas avec Sass.
  30. Avec des éléments parents qui peuvent être définis en %, px, em, etc. donc des conversions d’unité à chaque fois.
  31. Ce qui ne fait aucun doute si vous avez bien tout lu jusque là.
  32. Qui a eu l’excellente idée de partager de façon très détaillée son retour d’expérience de la mise en œuvre de Responsive Web Design élastique.

6 commentaires sur cet article

  1. bmenant, le lundi 9 décembre 2013 à 15:15

    Merci pour cet article hyper complet.

    Je voulais juste exprimer un désaccord sur la #cite-note-28 :
    « […] raisonner directement en em […] risque de brider la créativité visuelle. »

    À court terme, peut-être (temps d’apprentissage pour développer un savoir-faire), mais… Ne s’agit-il pas là de passer de la mise en page à la mise en scène ? Selon moi, c’est précisément une excellente opportunité offerte aux graphistes (dont certains ont déjà commencé l’exploration).
    Quelque part, cela m’évoque les livres « pop’up » (pour les enfants, souvent et malheureusement), dont chaque page s’animait d’un univers de magie.

  2. Nicolas Hoizey, le jeudi 19 décembre 2013 à 10:03

    @bmenant le soucis est que cela nécessite un apprentissage assez poussé par les graphistes des contraintes que cela implique pour eux. Certains feront — ou ont déjà fait — l’effort, mais sans doute assez peu malheureusement.

  3. François REMY, le dimanche 22 décembre 2013 à 17:42

    Au début défenseur de cette idée (j’ai même proposé une unité ”responsive pixel” valant 1px * 1rem / 16pt), j’ai avec le temps appris que laisser son layout à la libre interprétation de la taille de police par défaut du navigateur n’était en fait pas une très bonne idée.

    La première raison est que la taille de police est quelque chose de mal défini. Une même taille de police peut donner des tailles de lettres très différentes selon la police choisie : 11pt en Verdana ce n’est pas du tout pareil que 11pt en Cambria ou Times New Roman.

    https://twitter.com/FremyCompany/status/414760960482476032/photo/1

    Dans la plupart des sites web modernes, la police par défaut du navigateur n’est pas conservée et est remplacée par une autre police, qui colle mieux au design de notre site. La taille de police initiale n’est donc plus d’aucune utilité, vu qu’elle a été choisie pour s’adapter au mieux à une police qu’on utilise pas, et dont on ne sait presque rien (sauf si on fait des suppositions sur la police utilisée par défaut, qui est assez souvent la même sur une plateforme donnée – rendant notre design faussé sur toutes les plateformes s’écartant de cette hypothèse).

    En effet, en fonction du fait que la police sans-serif par défaut de la plateforme ressemble plus à Verdana qu’à Arial (et donc la taille par défaut un peu plus petite ou un peu plus grande pour compenser la design de la police), les lettres avec notre nouvelle police pourront être plus ou moins grande – et ceci sans lien aucun avec les conditions de vision de l’utilisateur !

    Ansi, je préconise de ne jamais utiliser la taille de police par défaut lorsque l’on change la font et d’imposer une taille de police fixe en pixels. Si l’utilisateur désire zoomer, il peut totalement le faire en utilisant la fonctionnalité de zoom de son navigateur, qui change la taille de tous les éléments à l’écran – en ce compris du texte, et permet de rester sûr que tout reste correctement en place.

    Cela retire tous les risques liés à des layouts trop petits pour le texte qu’ils contiennent, et cela offre une expérience consistante. Après tout, cette technique qui consiste à faire dépendre tout le layout de la taille de police est juste une émulation grossière d’un zoom global appliqué à la page, qui possède tous les mêmes avantages et défauts, tout en étant moins précis.

    Cette fonctionnalité visant à changer la taille de la police est par ailleurs elle-même une fonctionnalité de compatibilité datant de l’époque où il n’était pas possible de zoomer sur tout le layout en raison du mappage 1px = 1device-pixel encodé dans les navigateurs. De nos jours, cette fonction est cachée très profondément dans les paramètres des navigateurs alors que le zoom, fonction plus récente et destinée à la remplacer, est resté à portée de main.

    En conclusion, à moins d’avoir un îlot de texte sur lequel aucun layout particulier n’est appliqué (typiquement le contenu d’une balise ), il n’est pas recommandé de faire dépendre son style d’un paramètre dont la sémantique n’est pas claire et ne dépend pas uniquement de la volonté de l’utilisateur, surtout si l’utilisation de cette technique encourage l’utilisation d’un préprocesseur pour se simplifier le travail de conversion d’échelle.

    En effet, la plupart du travail de développement se fait dans les outils des navigateurs, qui n’ont que faire du code originel du préprocesseur, mais peuvent effectuer tout seuls de petits changements à nos fichiers sources si l’on se cantonne au CSS classique.

  4. François REMY, le dimanche 22 décembre 2013 à 17:45

    (autre point à prendre en compte : les navigateurs qui appliquent un zoom redimensionnent correctement et proportionnellement les contrôles utilisateurs //… alors que si on leur impose la taille nous-même, cela a des résultats plus ou moins heureux selon les plateformes vu le faible niveau de contrôle qu’on a sur ces éléments)

  5. Nicolas Hoizey, le lundi 23 décembre 2013 à 12:03

    @François : merci pour ce commentaire détaillé et argumenté !

    Je ne suis pas d’accord sur le fait que le zoom global soit une meilleure solution que le design élastique en em. Quelle surprise… ;-)

    Petite question au passage : pourquoi encore raisonner en unité « pt » sur le Web ?

    Je suis d’accord qu’il peut y avoir des écarts non négligeables de dimension de rendu des textes selon les polices de caractères utilisées, et j’avoue n’avoir pas eu l’opportunité de me pencher sérieusement sur les techniques de font-size-adjust et autres.

    D’ailleurs, tout comme je préconise de laisser la taille configurée par défaut pour le corps de texte, certains se demandent s’il ne faudrait pas aussi laisser la police par défaut, que l’utilisateur a pu modifier pour améliorer son confort. Je n’en suis pas là, je suis d’accord que les webfonts sont une avancée importante pour le web design, mais je me pose la question tout de même. Si on adopte un tel raisonnement jusqu’au boutiste, on peut aussi se dire qu’il faut laisser les couleurs de texte et de fond choisies par l’utilisateur, ce qui devient vraiment compliqué. La difficulté est donc de choisir où placer le curseur, et je suis convaincu que préserver la taille configurée pour le corps de texte est le bon endroit.

    Non, le zoom texte n’est pas « cachée très profondément dans les paramètres des navigateurs ». Dans Firefox, il est visible dans le menu de zoom lui-même. La possibilité de choisir une taille de texte par défaut est de même bien visible dans la fenêtre de paramètres. Si Chrome a fait le choix de virer complètement cette fonctionnalité de zoom texte — tout en préservant heureusement le paramétrage de la taille par défaut —, ce n’est pas une indication que personne n’en a besoin. J’ai trouvé sur divers forums de nombreux messages de personnes cherchant justement comment grossir le texte dans Chrome, et différentes extensions tentent (souvent mal d’après la demi-douzaine que j’ai testées) de répondre à ce besoin.

    Définir une taille de police arbitraire en px, c’est considérer que tout le monde à besoin de la même taille de texte pour une lecture optimale, ce qui est loin d’être le cas. C’est oublier que certains veulent définir une police par défaut plus grande, voire que certains appareils (des liseuses notamment) le font de base. Ces mêmes appareils ne proposent d’ailleurs pour certains par de zoom global, juste la possibilité de personnaliser la taille de texte par défaut.

    Pour finir, au sujet des préprocesseurs qui aident à l’intégration en « em » — sans forcément être nécessaires, puisque ce type d’intégration existait bien avant —, je ne suis pas sûr qu’il y ait déjà une grande proportion d’intégrateurs Web qui soient prêts à confirmer que « la plupart du travail de développement se fait dans les outils des navigateurs ». Quoi qu’il en soit, pour ceux qui le font déjà comme pour ceux — sans doute nombreux — qui y viendront progressivement, ce n’est pas du tout un argument contre les préprocesseurs, puisqu’il est déjà possible de faire du Sass directement dans Chrome : http://net.tutsplus.com/tutorials/html-css-techniques/developing-with-sass-and-chrome-devtools/

    En tout cas, heureux de voir que le sujet pousse à réfléchir, discuter, argumenter. J’exprime ma conviction, je sais qu’elle ne fait pas l’unanimité, donc avoir en commentaire des contres arguments permettra à chacun de faire son propre choix.

  6. François REMY, le lundi 23 décembre 2013 à 12:48

    Avec le nouveau design de FireFox 29, il faut en tout cas aller dans Menu > Options > Contenu pour pouvoir trouver les paramètres de police. Dans IE sur le bureau, la fonctionnalité n’est encore accessible que si on sait qu’il faut appuyer sur ALT pour faire apparaître l’ancien menu (elle n’est même pas dans les options) et, par conséquence, elle a totalement disparue du IE immersif. Enfin, elle n’existe pas dans Chrome ou Opera. Cela m’a tout l’air d’une fonctionnalité que l’on garde encore pour des raisons historiques dans les navigateurs plus anciens mais qu’on encourage plus les gens à utiliser :-)

    Pour ce qui est des appareils qui ne permettent pas d’appliquer un zoom global, je dirais que c’est à priori une erreur de conception du software de l’appareil. Si il y en a vraiment – c’est assez désolant – cela peut alors en effet servir de justification à l’utilisation de la taille de police par défaut comme coefficient de zoom alternatif, si du moins on estime le zoom nécessaire pour ces appareils.

    Cela dit, indépendamment de ça, je reste d’accord qu’utiliser la taille de police par défaut sur des longs textes (le contenu principal d’une page) reste dans certains cas une bonne idée – après tout, la police par défaut sert justement à cela.