Maintenant que les avantages indéniables des unités relatives pour la taille de fonte ont été posés du point de vue du respect des paramètres utilisateur, voyons leurs effets sur les media-queries.

Vous avez peut-être déjà pu voir certains effets sur les pens précédents.

Rappelons un fait : les media-queries sont un système pour adapter les contenus d’un site selon les caractéristiques du visiteur (largeur d’écran, etc.). En général, l’idée est de les adapter au mieux en fonction du design et du contexte de l’utilisateur. Ce « truisme » (je rêvais de placer ce mot depuis longtemps) tombe sous le sens, mais vous allez voir qu’il prend une certaine dimension dans notre sujet.

Au fait, les media-queries se basent sur quoi ?

Cela va peut-être vous surprendre, mais les media-queries se basent sur les préférences utilisateur ! Si vous n’en êtes pas convaincu, je vous prie de faire cette expérience sur cet exemple : une taille de fonte en unité relative (em). Vous noterez que j’ai défini un breakpoint à 50em (qui va faire apparaitre un texte).

Voila l’expérience en question :

• Mettez-vous en conditions « standard », soit avec une taille de fonte de 16px.
• 50 fois 16 = 800 pixels. Redimensionnez votre fenêtre, vous verrez apparaitre le texte en-dessous de 800px.
• Maintenant, augmentez votre taille de fonte par défaut à 32px.
• 50 fois 32 = 1600 pixels. Redimensionnez votre fenêtre (si elle fait plus de 1600px de large), vous verrez apparaitre le texte en-dessous de 1600px.
• Si comme moi, votre écran fait moins de 1600px de large, le texte sera déjà visible, et il va falloir agrandir votre fenêtre pour le faire disparaître.

Surprenant n’est-ce pas ?

Une erreur assez commune est de croire que les media-queries sont basées sur l’élément html. Ce n’est pas le cas, c’est bien basé uniquement sur les préférences utilisateur. Si vous doutez que l’élément html n’influe en rien, vous pouvez tester sur le pen suivant : une taille de fonte en em sans « reset ». Comme vous pourrez le voir, qu’il y ait un « reset » ou pas n’y change strictement rien, le comportement est le même.

Les paramètres utilisateurs, seulement la taille de fonte par défaut ?

C’est principalement la taille de fonte par défaut, mais… pas uniquement. L’utilisateur a deux autres possibilités : le zoom global et le zoom texte.

Le zoom global, comme son nom l’indique, effectue un zoom sur tous les éléments, vulgairement : tout le site grandit proportionnellement.

Le zoom texte, comme son nom l’indique aussi, n’effectue un zoom que sur le texte.

Il y a quelques subtilités en pratique entre ces deux zooms, nous allons voir lesquelles dans de futurs exemples. Si vous souhaitez tester sans tout faire à la main, je vous conseille d’utiliser une extension comme NoSquint, qui permet de tester directement avec l’un ou l’autre.

Alors, quid des media-queries en pixels ?

Comme dans le billet précédent, les pixels sont indépendants des préférences utilisateur. Ce qui suit va encore vous le prouver.

Si vous mettez en place une media-query en pixels, avec une taille de fonte par défaut à 16 ou 32px, elle ne s’appliquera que quand la fenêtre fera 800px. En quelque sorte, c’est l’écrasage « presque » ultime des préférences utilisateur.

Pour les zooms, c’est quelque peu différent. Comme le zoom global grossit tout (les préférences utilisateur comprises), la media-query s’appliquera quand le zoom sera à 200% (cela peut sembler assez intuitif). D’où le « presque » entre guillemets dans la phrase précédente.

Par contre, le zoom texte n’impactera pas le déclenchement de la média-query. Encore une fois, comme les pixels sont indépendants des préférences utilisateurs, cela semble plutôt logique.

Voir l’exemple sur Codepen : une taille de fonte en em avec une media-query en pixels.

Si vous regardez le pen tout en em, que ce soit en zoom texte ou en zoom global, la media-query s’appliquera à 200%.

Qu’en déduire pour nos sites ?

Une citation résume bien ce phénomène :

Designing for the Web is like visualizing a tesseract. We build experiences by manipulating their shadows. — Tim Brown

Traduction expresse : concevoir pour le Web est comme visualiser un tesseract (un cube à 4 dimensions), on construit une expérience en manipulant ses ombres (nous ne pouvons voir que 3 dimensions).

Vous pouvez tester sur le site de Röcssti. Le conteneur principal a été défini en em et les tailles de fonte ainsi que les media-queries ont été définies également en em.

En fait, travailler en em permet, sans le savoir, de travailler au mieux sur toutes les dimensions utilisateur (zoom, préférences de typo, zoom texte, etc.), sans même en avoir forcément conscience.

Si vous voyez la bibliothèque dans le film Interstellar, c’est exactement le même principe.

Vous avez le cas « standard » avec ses déclinaisons responsive. Imaginez-vous 3 ou 4 images sur une droite.

Maintenant, imaginons une troisième dimension, où l’on augmente la taille de fonte standard. On rajoute le zoom global ? Une dimension de plus.

Zoomez fortement sur le desktop ? Vous aurez l’adaptation mobile du cas « standard », sur un grand écran. Ayez une taille de fonte de base légèrement diminuée et un zoom texte léger ? Vous aurez peut-être le rendu tablette ou équivalent.

Et même parfois, vous aurez une singularité dans tout cela. Lisez Double breakpoint bug de Thomas Tzilliox, le cas où ces dimensions laissent un espace vide, en quelque sorte. :)

La (sur)vie avec les em

Le guide de survie avec les em du billet précédent n’était pas complet.

Après, je crée le site dans les conditions « standards », et ô miracle, changer la taille de fonte par défaut ne cassera rien.

C’est même le contraire, je ne casse rien mais je construis en même temps dans d’autres dimensions : les breakpoints que je définis pour le mobile dans le cas standard vont resservir pour toutes les variétés de réglages selon les périphériques ou les utilisateurs.

C’est quand même extraordinaire quand on y pense, car le fait d’adapter au mieux les contenus pour le cas « standard » (en gros, en connaissant sa division par 16), vous fait travailler en même temps pour de forts zooms sur desktop.

Pour de bon que si vous aviez le doute de travailler le responsive uniquement d’après les contenus plutôt que de viser des résolutions fixes, cela va achever d’enterrer ce doute.

En tout cas, j’espère que vous voyez mieux le sens de « lâcher prise sans perdre le contrôle » : vous n’avez pas prise sur les media-queries, vu qu’elles sont basées sur les préférences utilisateurs… sur lesquelles vous n’avez pas de prise. Et pourtant, vous pouvez faire au mieux, même pour un cas que vous n’imaginez pas.

Media-queries en rem

Ajout du 1 Mars 2018 : tous les tests précédents sont valables sur des media-queries en em. Les media-queries en rem créent une curiosité. Voyez le test une taille de fonte en rem avec « reset » sur une media-query en rem.

Firefox et Safari desktop vont déclencher le breakpoint à 500px (10 * 50rem = 500px) avec une taille de fonte par défaut à 16px et à 1000px avec une taille de fonte par défaut à 32px !

Chrome et Edge vont le déclencher à 800px et 1600px respectivement (ils se basent sur la préférence utilisateur, comme pour les media-queries en em).

En clair, évitez les media-queries en rem, le support en est inconsistant. Et honnêtement, je ne sais pas dans ce cas qui a raison côté navigateur.

Ajout : Chrome et Edge ont raison, Firefox a corrigé ce bug (le patch sera publié sur Firefox 59 à priori). Le bug est remonté chez Webkit pour Safari.