On met en pratique la théorie sur l’agrandissement des caractères.

Ce que j’ai fait :

Ajout d’unités relatives

La feuille de styles par défaut du blog comportait des unités en pixels et quelques tailles en em par-ci par-là. J’ai choisi d’utiliser l’unité relative rem sur l’ensemble du blog. Pourquoi du rem et pas du em ? La principale raison est que j’ai l’habitude d’utiliser cette unité et que je la trouve plus facile à manier car il n’y a pas de question d’héritage à gérer. Mais je ne suis pas anti em pour autant, je compte bien d’ailleurs utiliser cette unité dans un de mes projets futurs pour mieux me familiariser avec.

J’ai choisi de simplifier le calcul de conversion des px en rem en ajoutant la propriété suivante :

html {
  font-size: 62.5%; // to facilitate calculations, assuming that the base size is 16px
  font-size: calc(1em * 0.625);  // IE9-IE11 math fixing
}

En partant de l’idée que la taille par défaut d’un navigateur est de 16px, 62.5% de ces 16px donnent 10px à l’affichage. Les calculs sont donc grandement facilités :

p {
  font-size: 1.8rem /* taille équivalente à 18px */
}

Evidemment, la taille de base d’un navigateur peut ne pas être systématiquement de 16px ou bien l’internaute peut avoir modifier ses préférences pour avoir une taille de base de 24px. Mais cela ne pose pas vraiment de problème puisque dans tous les cas l’ensemble s’adaptera de manière fluide tout en respectant les préférences de l’internaute.

Quant à la ligne font-size: calc(1em * 0.625);, elle permet de corriger une erreur d’arrondi dans Internet Explorer pour qui une taille de l’élément html définie à 62.5% ne vaut pas 10px mais… 9.93px.

J’ai appliqué l’unité rem sur l’ensemble des tailles de caractères, mais également sur les margin et padding, afin que l’agrandissement des caractères et des espacements soit harmonieux.

J’ai également vérifié que les propriétés line-height ne comportaient pas d’unités.

Enfin, la taille du conteneur principal du blog est définie avec une largeur maximale de 740px de la manière suivante : max-width: 74rem;. Je me suis donc assurée que l’agrandissement global et uniquement du texte ne posait pas de souci avec cette propriété.

Tests avec le zoom du navigateur

L’agrandissement à 200%, uniquement du texte, ne pose pas de problème particulier. Le contenu reste lisible. Idem pour le test avec le zoom graphique.

Ce que j’ai appris

Un rappel très important et intéressant : les media-queries sont basées sur les préférences utilisateur, et non pas l’élément html. Sur le Codepen suivant(lien externe) (tiré de l’excellent article de Nicolas Hoffmann, Les media-queries et les préférences utilisateurs(lien externe)), vous pouvez constater le comportement strictement identique du media-query, qu’il y ait un reset de 62.5% dans l’élément html ou non.

Cela signifie donc que pour mon media-query précédemment défini avec un min-width: 640px, l’équivalent en rem sera non pas min-width: 64rem mais min-width: 40rem. Il faut en effet bien penser à diviser la taille par 16px, soit la taille de référence choisie pour nos calculs. Autrement dit, on aura bien :

@mixin desktop {
  @media screen and (min-width: 40rem) {
    // 640px / 16 = 40rem
    @content;
  }
}

Dans son article en date de mai 2016 et mis à jour en mars 2018, Nicolas Hoffmann évoque plusieurs problèmes de support des rem dans les medias-queries, notamment sur Firefox et Safari qui ne déclenchent pas le breakpoint au bon moment. Le problème a depuis été résolu sur Firefox et cela semble également être le cas sur Safari puisque le site Can I Use(lien externe) annonce un support total de l’unité rem et ne signale un souci de compatibilité avec les medias-queries que pour les versions iOS 5.0 et 5.1.