Refonte de mon portfolio : du responsive tout en EM (première partie)

Un mot avant de commencer

Voici le quatrième et dernier billet consacré à la refonte de mon #Portfolio­Of­Doom, et plus précisément à l'intégration d'un site web tout en em.

Ce billet est énorme : je sais que j'écris toujours des tartines, mais là, ça a dépassé toutes les bornes. J'ai passé plusieurs soirées, pas mal de pauses déjeuner et quelques dimanches à l'écrire. J'avais envie de rentrer dans les détails, car il n'existe pas, à ma connaissance, beaucoup de ressources en français sur le sujet.

À cause de son caractère exceptionnel, j'ai décidé, exceptionnellement, de découper ce billet en deux parties :

1. La première partie, publiée aujourd'hui, s'attache à démontrer l'intérêt d'une intégration tout en em, media queries comprises, et tests à la clé.
2. La seconde quant à elle me permettra de rentrer dans le détail des outils et des méthodes que j'ai mises au point pour intégrer un site en em aux petits oignons.

Ce billet va être un tout petit peu plus technique que d'habitude, mais je vous rassure, le lire ne vous fera pas mal – vous ressentirez juste un petit chatouillement dans le bout des doigts !

Edit : la seconde partie de ce billet est en ligne.

Valeurs relatives vs. valeurs fixes : le choc des titans

Depuis que j'intègre des sites (a long, long time ago), j'ai toujours lu qu'utiliser des valeurs relatives comme les em ou les pourcentages plutôt que des valeurs fixes (px, in, pt, ou cm) pour définir ses tailles de texte en CSS est mieux pour le bien de l'humanité.

Pourquoi donc ?

L'unité em permet de définir une taille – de texte, par exemple – qui soit relative à la taille de police sélectionnée par l'utilisateur dans les préférences de son navigateur.

Seulement voilà : la théorie, c'est bien gentil, mais rien ne vaut un exemple concret pour comprendre l'avantage d'intégrer un site tout en em.

Test d'un site tout en em

La plupart des gens ne modifient jamais la taille de police minimale de leur navigateur. Ce paramètre est pourtant simple à modifier :

• Dans Firefox : Préférences > Contenu > Polices et couleurs
• Dans Chrome : Préférences > Paramètres > Afficher les paramètres avancés > Contenu web > Personnaliser les polices… > Police standard

Par défaut, la taille de la police est réglée sur 16 pixels. Sur une résolution 1280x1024, mon site ressemble à ça :

C'est ce qu'on appelle la version « desktop »¹.

Si vous changez la taille de la police par défaut dans votre navigateur pour du 24 pixels par exemple, vous verrez un changement, sans avoir à redimensionner votre viewport² :

Que s'est-il passé ? Comme toutes les déclarations CSS chiffrées et les media queries de mon site sont déclarées en em, celui-ci a automatiquement basculé sur la version « tablette » parce que la taille de police du navigateur a été agrandie.

Si on modifie à nouveau la taille par défaut du navigateur, et qu'on la pousse jusqu'à 36 pixels, la version « mobile » est alors affichée, sans que j'aie redimensionné mon viewport là non plus :

Génial, non ? :grin:

On est ainsi sûr que l'utilisateur qui a besoin d'une taille de police aussi grande que ça pour pouvoir consulter confortablement mon site pourra le lire dans des conditions optimales, en fonction non seulement de son propre choix de taille de police, mais aussi des dimensions de son viewport.

S'il fait un zoom texte avec son navigateur, c'est non seulement les textes mais également tout le site qui s'adapteront à ce réglage pour lui assurer la meilleure expérience possible.

Intégrer un site tout en em peut ainsi être décrit comme du web design proportionnel, car les proportions des textes et des blocs sont toujours conservées, et ce quel que soit le niveau de zoom et/ou les réglages typographiques faits par l'utilisateur dans son navigateur.

Si on agrandissait le texte en 36 pixels mais que le layout de mon site conservait les mêmes dimensions que sur la toute première capture d'écran (1280 en 16 pixels), c'est à dire si j'avais défini, en CSS, les tailles de polices en em mais toutes les autres valeurs en pixels, imaginez un peu le désastre !

C'est pourquoi il est important de déclarer toutes les valeurs CSS chiffrées en valeurs relatives, et pas uniquement les font-size et line-height.

Notez que mon site aurait pu basculer plus tôt ou plus tard en mode « tablette » ou en mode « mobile » si la largeur du viewport avait été plus grande, ou bien si le choix de taille de police par défaut avait été plus petit. L'affichage de mon site est fonction des choix de l'utilisateurs et des dimensions de la fenêtre de son navigateur.

Si je rétablis la taille de police de mon navigateur à 16 pixels, et que je redimensionne mon viewport à 640 pixels de large, la version « mobile » se déclenche là aussi, mais la taille des textes n'a pas grossi :

Ces quelques tests démontrent que mon site est calibré pour s'adapter aux choix et au viewport spécifique de chaque utilisateur.

Vous pouvez encore le vérifier en utilisant ish, un petit outil créé par Brad Frost pour tester la « responsivité » (sic) de n'importe quel site : allez sur ish, cliquez sur le bouton « Size » situé en haut à droite de votre écran, puis sélectionnez l'option « Disco ». Déconseillé aux épileptiques ! :idea:

Précision langagière

J'ai mis les mots « desktop », « tablette » et « mobile » entre guillemets, car ce petit test prouve bien que les media queries ne servent pas uniquement à afficher la version mobile d'un site sur un périphérique mobile.

Une media query définie en em permet d'afficher la version mobile sur un écran d'ordinateur par exemple, dès lors que l'utilisateur a soit modifié la taille de police par défaut de son navigateur, soit effectué un zoom page ou un zoom texte sur mon site.

C'est pour cette raison que parler de version « mobile » ou de version « tablette » n'est pas tout à fait exact, et c'est pourquoi on parle de plus en plus de versions « S », « M », « L » et « XL » d'un site.

Test d'un site tout en pixels

Nous venons de tester la façon dont répond un site tout en em à différents réglages. Réitérons maintenant ces tests avec un site intégré tout en pixels³.

Si je prends l'exemple du site de la Fnac, par exemple, et que je refais les mêmes tests, vous allez voir les limites d'une CSS écrite tout en pixels.

Voici le site de la Fnac dans un navigateur dont la taille de police est réglée en 16 pixels :

Si je change la taille de police du navigateur pour du 24 pixels, voici ce qu'il se passe :

Il ne se passe rien, tout simplement parce que les tailles sont définies en pixels, donc en valeurs fixes, par opposition aux valeurs relatives que j'utilise, moi, sur mon site.

Inutile donc de faire le test d'une taille de police de 36 pixels, le site de la Fnac n'y réagira pas plus.

En revanche, on peut quand même vérifier si le site de la Fnac est responsive, comme ça, juste pour le plaisir.

Redimensionnons donc notre viewport en 640 pixels de large pour voir ce qu'il se passe :

Il ne se passe rien non plus !

Le site de la Fnac ne s'adapte donc pas du tout aux réglages effectués par l'utilisateur, et il n'est pas responsive non plus. Deux défauts qui rendent sa consultation beaucoup plus difficile, d'autant plus que la taille de police par défaut sur leur site est de 12 pixels, ce qui n'aide pas !

NB : le site de la Fnac n'est certes pas responsive mais il en existe un site mobile dédié. Il faut utiliser un téléphone pour y accéder. De là, on a ensuite le choix de revenir sur la version « classique », ce qui permet de consulter le site desktop sur un périphérique mobile.

En revanche, l'inverse n'est pas vrai : sur la version desktop, on a aucun moyen d'accéder au site mobile (même sur la page « Services mobiles Fnac », la bannière vantant le site mobile n'est pas cliquable). Mais je m'égare… :mad:

L'intégration en em est-elle utile ?

Voilà la question à mille balles que les intégrateurs se posent aujourd'hui : les em, est-ce encore utile aujourd'hui ?

Il faut dire qu'on a tellement assimilé l'intégration tout en em à une corvée insurmontable, qu'on a du mal à passer outre ce blocage psychologique. Je me demande même si on n'aurait pas tendance à arguer systématiquement que « les navigateurs n'ont plus besoin de valeurs relatives aujourd'hui » par angoisse de devoir calculer, de tête, dix chiffres après la virgule, comme une punition !

Heureusement, les outils dont on dispose aujourd'hui permettent de se simplifier énormément la tâche : les préprocesseurs CSS (LESS, Sass et Stylus) peuvent faire tous ces calculs pour nous ! Sauvés !

Grâce à ce petit mixin, au lieu d'écrire :

.girdenwodan
{
	margin-bottom: 20px;
}

J'écris désormais :

.girdenwodan
{
	margin-bottom: em(20px);
}

Et Compass génère automatiquement l'équivalent en em de 20 pixels.

Je peux aussi définir simplement un contexte particulier :

.girdenwodan
{
	$fs1: 16px !default;
	@include font-size($fs1);
	margin-bottom: em(20px,$fs1);
}

Et hop !

Personnellement, j'ai trouvé qu'intégrer un site tout en em demande, la première fois, un certain temps d'adaptation et une mise à jour de ses réflexes de codage. Mais on se prend vite au jeu, ça devient un défi technique vraiment sympa à réaliser.

Les em vs. les outils de zoom des navigateurs modernes

Cependant, il est quand même légitime de se demander si cet investissement est réellement utile puisque les navigateurs modernes rendent déjà les sites intégrés tout en pixels zoomables.

En effet, les fonctions de zoom proposées par les navigateurs modernes permettent d'augmenter la taille de toute la page (zoom page) ou uniquement des textes qu'elle contient (zoom texte), et ces outils de zoom fonctionnent même sur les sites intégrés en valeurs fixes, même si les media queries ont été également déclarées en pixels.

Reprenons le site de la Fnac :

Si j'utilise le zoom page dessus, celui-ci s'agrandit proportionnellement comme le mien ! Et pourtant, on a vu qu'ils ont été intégrés de manières très différentes :

Le navigateur a zoomé lui-même le site, et a ainsi pallié l'intégration en valeurs fixes qui en a été réalisée.

Cela dit, cela ne rend pas pour autant le site responsive, et, comme nous l'avons vu précédemment, le site ne s'adapte pas aux réglages typographiques de l'utilisateur. Cela contraint donc l'utilisateur pour qui ce site est difficile à lire à zoomer manuellement à chaque fois qu'il veut consulter ce site. Ce n'est clairement pas optimal.

Utile… pour un petit nombre d'utilisateurs

L'intégration en em n'est a priori réellement utile qu'à une toute petite partie de la population : celle qui est encore bloquée sur les vieux navigateurs qui ne proposent pas de zoom page (Internet Explorer 6 par exemple).

Internet Explorer 7 et 8 quant à eux proposent une fonctionnalité de zoom page, mais ils ont du mal à agrandir les textes définis en pixels⁴ ou autres valeurs absolues. Donc, une intégration en em facilite le zoom dans ces navigateurs-là.

Le fait d'avoir intégré toutes les valeurs chiffrées en em permet à l'utilisateur qui ne possède qu'un zoom texte de zoomer tout le site, et pas seulement les textes. On apporte ainsi une meilleure fonctionnalité de zoom à l'utilisateur, en complétant, grâce à notre CSS, la fonctionnalité de zoom de son navigateur.

Mais je prêche un peu dans le désert, vu que mon propre site n'est ni compatible IE6 ni IE7 !

Alors pourquoi m'être donné tant de mal ? Je me suis lancée dedans principalement pour le défi technique que cela représente (je reviendrai sur les mixins que j'utilise dans la seconde partie de cet article).

Par ailleurs, j'apprécie le fait que mon site ne craque pas dès qu'on zoome ou qu'on change les tailles de police dans son navigateur, ou qu'on le consulte sur un périphérique quelconque.

Si quelqu'un visite mon site sur son téléviseur réglé en 24 pixels, hop, ça fonctionne. Si quelqu'un l'affiche sur une liseuse dont la taille par défaut est de 21 pixels, hop, ça fonctionne⁵.

Ok, vous pourriez penser que ce sont des cas extrêmement à la marge – mais je pense que ce type de réglages exotiques vont encore se démocratiser, d'autant plus que la génération des digital natives commence doucement à vieillir et que leurs usages vont encore évoluer.

Je ne considère donc pas l'intégration en em comme un développement spécifique, mais juste comme un niveau d'accessibilité supplémentaire.

Résolutions et périphériques vs. échelles et proportions

Enfin, les media queries en em quant à elles apportent un réel confort d'utilisation à l'heure où la taille et le nombre d'écrans utilisés pour consulter des contenus web se multiplient. Les media queries en em nous obligent à ne plus penser en terme de résolution ni de périphérique, mais bien en terme d'échelles et de proportions.

À ce sujet, l'article 7 Habits of Highly Effective Media Queries de Brad Frost achèvera de vous convaincre de l'utilité des media queries en em.

Certes, nous sommes en 2013, et l'unité rem commence à faire son bonhomme de chemin. Néanmoins, quand on a encore une contrainte IE8 ou en-dessous, je pense que ça vaut encore le coup d'intégrer ses sites en em, ne serait-ce que pour l'avoir fait une fois dans sa vie d'intégrateur ! :razz:

À suivre : dans la seconde partie de ce billet, j'aborderai les mixins utilisés, l'épineuse question des images et des sprites proportionnels ainsi que les grilles macrotypographiques. Je le publierai dans les jours qui viennent.

Et pour celles et ceux parmi vous qui ne me suivent ni sur Twitter, ni sur Facebook, et qui n'utilisent pas RSS, abonnez-vous à mon blog par email pour recevoir un joli petit email à chaque fois que je publie un nouveau billet (une fois par semaine maximum).

Sur ce, je vous laisse, je dois préparer mon baluchon pour Paris Web ! ^.^\m/

Edit : la seconde partie de ce billet est en ligne.