Les media-queries et les préférences utilisateurs

Les media-queries et les préférences utilisateurs (le 15/05/2016)

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.

InterStellar

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.

Permalien :

Flux RSS des commentaires de ce billet : https://www.nicolas-hoffmann.net/rss/commentaires.php?id_news=1693

5 commentaires

Posté par Loïc le 03/06/2016 à 12:22:58
Bonjour Nicolas et merci pour ce super article.

Comme tu l'indiques, "travailler le responsive uniquement d’après les contenus" est désormais une bonne pratique reconnue.
J'ai en revanche une petite question qui me traîne dans la tête depuis un bon moment déjà...

La réalisation d'un site complet comporte très souvent différentes pages qui peuvent avoir un layout complètement différent : une page au format sidebar 1/3 + contenu 2/3, une page avec 2 colonnes égales, une page "full frame", etc.

Si l'on travaille le responsive des pages d'après leurs contenus, est-ce qu'il ne serait pas logique que chaque page possède ses propres breakpoints pour qu'elles puissent s'afficher parfaitement en toutes circonstances ?

A l'heure actuelle je n'ai pas trouvé de ressources qui évoquaient cette problématique car j'ai l'impression que tout le monde définit ses points de rupture de manière globale pour un site. Idem pour les frameworks UI: quand on utilise une grille CSS ou un framework comme Bootstrap & co, les breakpoints sont globaux pour l'ensemble du site.

J'aimerais vraiment avoir ton avis sur ce sujet (clin d’oeil)
Posté par Nico le 03/06/2016 à 19:59:27
@Loïc : en théorie, oui, chaque page devrait avoir ses breakpoints propres selon ses contenus.

En pratique, je procède un peu différemment : pour éviter que les CSS n'enflent trop avec 10000 breakpoints, j'essaie d'harmoniser. Si un contenu nécessite un breakpoint à 800px et un autre à 780, je vais essayer de voir pour les mettre sur le même breakpoint (si c'est possible bien sûr).

Après, je pars plutôt sur le côté responsive non pas des pages, mais plutôt des composants : responsiver la navigation, tel module, etc.

En concevant de manière suffisamment élastique (vivent les unités relatives comme les %) et robuste (en faisant des modules qui se stretchent bien), on arrive à limiter le nombre de breakpoints.

Après, avec un peu de pratique, tu arrives à voir rapidement où vont être tes breakpoints majeurs (en général, apparition du burger icon, quand la nav desktop n'est plus possible, etc. même si ce n'est pas forcément une règle absolue). Sur des templates plus compliqués comme celui que je suis en train de faire, j'ai 5 breakpoints majeurs au lieu des 2 ou 3 habituels.

Avant, j'avais tendance à fixer les breakpoints au dernier moment avant que les contenus ne soient étriqués, maintenant, j'aurais tendance à prévoir un peu de marge, j'aime bien que les contenus respirent, et ça tolère plus facilement des changements imprévus.

Voilà, j'espère que cela répond à ta question ? Sinon, n'hésite pas.
Posté par Loïc le 19/06/2016 à 12:57:46
Bonjour Nicolas et désolé pour le léger retard de ma réponse.

Oui ton explication est très claire! J'avais également une optique relativement similaire en tête (essayer d'harmoniser au maximum les breakpoints principalement par grand type de layouts/contenus d'un site + placer des breakpoints sur certains composants centraux).

Dans tous les cas un grand merci pour ton partage d'expérience et pour le temps que tu prends pour nous répondre et nous faire des articles de qualité (clin d’oeil)
Posté par David le 21/12/2017 à 10:23:53
Salut Nico,
Juste pour t'informer que la version 10.x de Safari foire complétement avec les médias queries quand tu zoomes la page.
https://adamwathan.me/dont-use-em-for-media-queries/

Je ne pense pas abandonner son support malgré tout.
1/ Ce serait privé les autres utilisateurs (majoritaires) du respect de leurs préférences
2/ Le contenu reste accessible malgré tout même si dégradé par rapport à ce qui est prévu
3/ On fait des sites qui existeront encore demain. Ce bug sera peut être (pas?) résolu à l'avenir.
Posté par Nico le 21/12/2017 à 14:38:15
David : Le bug est fixé sur iOS11 à ce que je lis dans le billet que tu mentionnes. Merci pour l'info (clin d’oeil)

Ajouter un commentaire









L'option « Se souvenir de mes informations » utilise un cookie, elle ne sera pas effective si vous les avez désactivés.

Les balises HTML ne seront pas interprétées, il est donc inutile d'en mettre. Par contre, les sauts de lignes de votre commentaire seront pris en compte, ne mettez donc pas de <br />, le site s'en chargera. Bien sûr, un commentaire vide ne sera pas ajouté !

L'auteur (autrement dit moi) n'est pas responsable des éventuelles fautes d'orthographe dans les commentaires.
Tout propos raciste et/ou insultant sera supprimé sans préavis. Les commentaires hors de propos destinés à faire de la pub pour des sites seront également supprimés sans ménagement.

Je vous prie de me pardonner, j'ai énormément de mal à lire le "langage" SMS, il n'est donc pas du tout interdit de s'abstenir de l'utiliser. Qui plus est, vous avez sûrement un clavier digne de ce nom et pas celui d'un téléphone portable. Ne vous gênez pas pour utiliser l'option "Prévisualiser" si vous voulez vous relire avant de poster, je vous en remercie d'avance !

Cet article a été écrit par Nicolas Hoffmann.

Ce site est la propriété de Nicolas Hoffmann.
Tous droits réservés, les textes du blog sont publiés sous licence CC BY-NC-SA.