L’astuce du font-size: 62.5%; oui, non ou « ça dépend » ?

raphael

font-size

En 2004, un article très astucieux et nommé “How to size text using ems” introduit la notion de taille de police de base définie à la valeur “62.5%”.

L’astuce part du principe que quasiment tous les navigateurs appliquent par défaut une taille de police de base (1em) qui vaut 16 pixels.

Le coefficient multiplicateur de 62.5% permet alors de poser une base de 10 pixels au lieu de 16.

Pourquoi 10px ? Parce que cela facilite évidemment grandement les calculs des em par la suite :

body {
  font-size: 62.5%; /* base de "10px" au lieu de "16px" */
}
p {
  font-size: 1.8em /* j'ai une taille équivalente à 18px */
}

Euh, pourquoi pas des pixels ?

Avouez que ce serait quand même rudement plus simple d’écrire ça :

body {
  font-size: 10px;
}
p {
  font-size: 1.8em /* j'ai une taille équivalente à 18px */
}

La raison est simple : le pixel est une unité fixe qui n’est pas accessible et qu’il est difficilement modulable dans des contextes variables (Responsive Webdesign notamment).

Si la taille de base est exprimée en pixels, alors l’ensemble des tailles de polices des descendants, même si elle est exprimée en unités fluides, demeurera figée. Et ça c’est mal pour vos visiteurs qui doivent pouvoir agrandir les contenus s’ils le nécessitent.

<body> n’est pas <html> et em n’est pas rem

L’usage historique était d’appliquer font-size: 62.5% sur l’élément <body> pour l’associer à l’unité em.

Cette technique est, je le concède volontiers, très risquée en raison des inévitables soucis de cascade que nous allons irrémédiablement rencontrer dans nos intégrations et qui sont très bien expliqués dans l’article (anglais) “The weird 62.5% antipattern”.

Fort heureusement, l’unité rem supportée depuis IE9 change radicalement la donne.

En redéfinissant la taille de police de la racine <html> (et non <body>) et en employant ensuite l’unité rem (et non em), le problème de cascade ne se pose plus du tout. Et cela ne nous empêche pas de continuer à employer em lorsqu’on souhaite bénéficier épisodiquement de la cascade.

Oui mais la taille de base n’est pas toujours de “16px”

Ça c’est tout à fait vrai. Et Nicolas Hoizey vous le confirmera.

On peut par conséquent se poser des questions du type : “Et si mon navigateur a une taille de base de 24px ?”, ou bien “si moi-même j’ai modifié mes préférences à 24px ?”.

Bah d’accord, mais quel est le souci ?

Pour ce visiteur particulier, la taille de référence ne sera pas équivalente à 10px mais à 15px, ce qui n’est vraiment pas un problème vu que tout demeurera homogène et fluide tout en étant adapté aux préférences utilisateur.

Faudra-t-il redéfinir toutes les tailles ?

Dans le superbe livre CSS3 pratique du design web (que j’ai co-signé, je l’avoue), il est stipulé :

Malheureusement, je me dois de faire l’avocat du diable et de vous intimer de cesser cette mauvaise pratique. Effectivement, cette astuce transforme des calculs pénibles en simples opérations mentales, mais elle présente aussi des inconvénients.
En effet, elle va nécessiter de redéfinir la taille de la police de tous les conteneurs textuels, tels que p, li, les titres, et bien d’autres encore. Les calculs sont donc plus simples, mais en même temps plus nombreux !

Mais ce que ne dit pas le livre est qu’il n’est pas du tout nécessaire de devoir redéfinir la taille de tous les éléments textuels… il suffit d’ajouter une règle très simple sur <body> :

html {
  font-size: 62.5%; /* équivalence "10px" sur l'élément racine */
}
body {
  font-size: 1.4em; /* taille de base pour tous les éléments équivalent 14px */
}

C’est aussi simple que cela, car du coup n’importe où que nous soyons dans le code il se passera ceci :

p {
  /* j'ai une taille équivalente à 14px */
}
li p {
  font-size: 1.8rem /* j'ai une taille équivalente à 18px */
}
div {
  font-size: 1.2em /* j'ai une taille de 1.2x celle de mon parent */
}

En bref, avec cette technique :

  • on conserve une taille de base fluide, ici de 1.4em/px pour tous les éléments (= on ne casse rien du tout et il n’y a strictement rien à redéfinir)
  • on bénéficie d’une compréhension et d’une maintenance de code ultra-simplifiée dès lors qu’on utilise des rem sans pré-processeurs.

Et pourquoi pas 0.625em alors ?

Utiliser une unité typographique telle que des em plutôt que des pourcentages serait bien plus logique en effet.

Oui mais voilà, une taille de référence exprimée en em provoque des bugs sur IE6-IE7.

Ceci dit, je pense pouvoir affirmer que l’on peut à présent ne plus se soucier de ces dinosaures et que la syntaxe suivante semble finalement plus “propre” :

html {
  font-size: .625em; /* oui, on peut omettre le "0" avant le point */
}

Ah oui mais non (IE le retour)

Autre hic non insignifiant : IE9-IE11 a parfois un bug d’arrondi avec les pourcentages.

En clair, si vous définissez une taille de référence de font-size: 62.5%; ou même de font-size: .625em;, ce coquin de IE ne calculera pas “10px” mais… “9.93px” !

Ce bug est référencé depuis 2014 chez Microsoft, et la réponse officielle est “OSEF” (plus précisément “At this time we do not plan on making this change.”).

Il a donc été trouvé une solution de contournement mettant en oeuvre la valeur-fonction calc() reconnue depuis IE9 :

html {
  font-size: calc(1em * .625); /* IE9-IE11 math fixing. See http://bit.ly/1g4X0bX */
}

Et pourquoi pas un mixin ou un outil pour ça ?

À l’ère des préprocesseurs CSS et de la mode des mixins à tout va, l’on peut se dire qu’on pourrait laisser des outils se charger de ce genre de tâches ingrates.

Ceci étant dit, il y a une différence fondamentale entre un mixin perso et le combo 62.5% + rem :

  • écrire font-size: 2rem; c’est standard, reconnu, conventionnel et sans surprises.
  • écrire un mixin Sass tel que celui-ci… ne l’est pas :
@mixin em($size, $base: 16px) {
  $calcul: $size / $base;
  font-size: $calcul * 1rem;
}
p {
  @include em(20px);
}

Personnellement, j’ai un peu de mal à utiliser un plugin ou un mixin dont le nom ou l’usage risque de changer à chaque projet, plutôt que d’écrire font-size: 1.4rem qui est une syntaxe standard.

Conclusion

Pour clore ce sujet (vous voyez qu’on peut écrire pas mal de choses sur une simple valeur de “62.5%”), j’aurais tendance aujourd’hui à conseiller la syntaxe ci-dessous, que je pense “bulletproof” (sauf si vous me convainquez du contraire) :

html {
  font-size: .625em; /* fallback IE8+ */
  font-size: calc(1em * .625); /* IE9-IE11 math fixing. See http://bit.ly/1g4X0bX */
}
body {
  font-size: 1.4em; /* base font-size is equivalent "14px" */
}

Avez-vous des arguments à l’encontre de cette astuce ?
Connaissez-vous des cas concrets où cela provoque des bugs ou des désagréments ? Si oui, disposez-vous de sources ?

Le débat est ouvert !

EDIT : pour poursuivre vos investigations sur ce thème, je vous invite à parcourir l’excellent billet de Nicolas Hoffmann intitulé « Les em/rem avec les préférences utilisateurs ».

EDIT 6 juillet 2016

Cet article a été beaucoup commenté et certains arguments contre cette pratique sont plutôt convaincants, cela dépend donc finalement de beaucoup de choses dont les types de projets, les méthodes d’intégration et la nécessité de respecter ou non les maquettes graphiques.

Une autre façon d’appréhender les choses serait peut-être de :

  • conserver la taille de police de base (100%) sur <html>
  • utiliser systématiquement des rem lorsqu’on souhaite une valeur non cascadée
  • se servir de variables / préprocesseurs pour éviter les calculs :
// …
$f12: 0.75rem;
$f13: 0.8125rem;
$f14: 0.875rem;
$f15: 0.9375rem;
$f16: 1rem;
$f17: 1.0625rem;
$f18: 1.125rem;
$f19: 1.1875rem;
$f20: 1.25rem;
//

Merci à tous ceux qui entretiennent ce débat.

34 réflexions au sujet de « L’astuce du font-size: 62.5%; oui, non ou « ça dépend » ? »

  1. Merci pour cet excellent article et ses précieuses infos !
    Une vraie plaie ces tailles de fonts couplées à du responsive design.

  2. Honnêtement, j’ai jamais rencontré de cas où cette astuce est prise en défaut (si on applique une taille de fonte sur le body, bien sûr). Pas pour rien que je l’utilise depuis des plombes dans Röcssti. :o)

    En fait, la seule différence est une simple vision de l’esprit (comme je l’ai écrit ici http://www.nicolas-hoffmann.net/source/1692-Les-em-rem-avec-les-preferences-utilisateurs.html) :

    « Bref, avec ou sans « reset » et en em ou en rem, le résultat est le même, seules quelques valeurs changent. C’est juste un peu de gymnastique intellectuelle, à votre convenance ! Si vous préférez que 1rem soit équivalent à 10px pour vos calculs ou qu’il soit égal à « une fois la taille de fonte par défaut », c’est à votre convenance, je ne suis pas sectaire. »

    D’ailleurs, sur la dernière version de Röcssti, j’ai carrément mis l’option d’activer ce reset ou non, comme ça fin du troll.

    Pour l’effet sur les media-queries (comme expliqué dans le billet http://www.nicolas-hoffmann.net/source/1693-Les-media-queries-et-les-preferences-utilisateurs.html) :

    « 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. »

    In fine, c’est une simple question de goût et de couleurs.

    1. Ah mais ils sont extra tes deux articles, pourquoi ne me l’as-tu pas dit avant ? :p
      Je vais ajouter l’un d’entre eux en conclusion, merci.

  3. Et pourquoi avoir besoin de penser les fonts en pixel, et pas en em directement ?

    1. Ce n’est pas faux ce que tu dis, mais soyons honnêtes les « em » sont – parfois – une plaie (c’est bien pour cela que ce type d’astuce existe depuis 12 ans maintenant).

      Concrètement, quand je lis 2.5rem, je sais que ça fait 25px, tandis que quand je lis 2.5em… :/

      1. On peut se dire que 2.5em c’est « deux fois et demi plus grand’.
        Ce que j’essaye de comprendre, c’est pourquoi vouloir que ça fasse 25px, puisque ça ne sera jamais la même hauteur entre les différents navigateurs / configuration des nav. / devices.
        Si on configure le navigateur par default sur 24px, finalement le rapport 1em = 10px ne fonctionne plus ?

      2. Honnêtement j’ai arrêté complètement de réflichir «pixel». Lorsque je met mon h1 à 2.5em je n’ai aucune idée de la taille que cela fait en pixel, et à vrai dire je m’en fiche. Certes c’était déstabilisant au début mais une fois habitué on se sent plus à l’aise avec la réalité du web aujourd’hui. J’ai basardé les références en pixels avec les layouts Photoshop pour des outils plus adaptés.

        Si on rajoute que sur un projet je tente toujours de minimiser au maximum les différentes tailles de police cette «astuce» semble de plus en plus «peu utile». Mais bon tout cela dépend aussi de la méthodologie de travail.

        Aujourd’hui au lieu d’écrire 0.8394583em pour faire exactement 14px, j’écrirai plutôt 0.8em et peu importe la taille en pixels. Hormis sur l’élément racine ou je fait en sorte que la taille soit en pixels entiers pour d’éventuels et rare besoins «pixel-perfect» dans le site.

        1. @Kustolovic
          C’est un peu le sentiment que j’ai, je n’ai jamais eu besoin de réaliser du pixel perferct depuis un gabarit « pixelisé », et du coup les tailles de polices était 0.8 fois plus petite, 2 fois plus grande, etc…
          C’est effectivement plus compliqué a gérer si tu doit te conformer au pixel. Sans ça, c’est tout a fait gérable, avec la bonne utilisation des em/rem

  4. @Raphaël :

    • « Ce que j’essaye de comprendre, c’est pourquoi vouloir que ça fasse 25px » –> parce qu’on ne définit pas forcément une taille par rapport à un parent. Quand tu dois intégrer un gabarit dont la taille de police de la sidebar est de 14px sur le .psd (ajouter ici plein d’exemples), tu n’as pas forcément envie de calculer, de deviner la structure, de casser la cascade précédente avec un moche 0.35413em, etc. Et que font-size: 1.4rem; résout le problème.
    • « Si on configure le navigateur par default sur 24px, finalement le rapport 1em = 10px ne fonctionne plus ? » –> non, mais c’est exactement ce que je dis dans la partie « Oui mais la taille de base n’est pas toujours de “16px” ». Si elle est de 24px le rapport ne sera pas de 10px mais ça ne change strictement rien pour toi et ça ne casse rien pour l’utilisateur.

    1. D’accord, je comprend mieux, ça sert quand tu as besoin d’être « pixels-based » avec un gabarit au départ.
      Je viens de lire également les articles de Nicolas, qui m’ont pas mal éclairés.
      Merci pour vos explications à tous les deux 🙂

  7. Pour répondre à ton Tweet et approfondir:

    Un soucis de cette démarche est que la base 10 n’échappe pas au problème pénible de cascade d’ajustement de +/- 1 pixels d’un element parent.

    Admettons une base 10 avec 1.8em (18px). Si tu veux l’ajuster a 19px, il te faudra calculer sur une base 18, et ainsi de suite, si tu désire une valeur absolue. Certes, comme tu l’indiques, tu peux utiliser le rem unit uniquement pour éviter cela. Mais c’est une démarche différente qui n’est forcement adéquate dans tous les contextes.

    Personnellement, jusqu’à présent, j’évites généralement le calcul de cascade et reste sur une base 16 pour des ajustements mineurs. (e.g. 1.063em pour +1 ou 0.938em pour -1px). La base 16 étant large. Il y beaucoup moins de chances que cette l’erreur d’ems en cascade est une influence sub-pixel majeure sur les rapports de taille en pixels désirés. Et dans le cas de il m’est rare de vouloir définir une taille en px précise.

    Si on considères que le base font-size de reste variable par default (ne serait-ce que pour des changement d’auteur dépendant de la taille d’écran, par exemple). Des ajustement en cascade de + ou – 6.25% me semble suffisant pour du texte. et l’idée d’une taille px absolu pour le texte devient beaucoup moins viable ou importante.

    Une base 10 te ne donnes pas la même souplesse. Et elle agrandis la marge d’erreur dans le cas ou l’utilisateur change de « font default » pour laquelle tu ne peux plus garantir que tes proportions soit absolues.

    Je ne suis pas à l’encontre de cette technique. Mais je restes plutôt retissant à l’adopter de manière globale pour ces raisons.

    1. @hexalys

      Pour toute la première partie de ta réponse, on est d’accord que le problème de cascade que tu évoques ne vaut que pour des unités en « em ». On sort donc du sujet puisque l’astuce décrite est basée sur les « rem ».

      J’ai du mal à comprendre ton argumentaire de « souplesse » allouée par une base 16.

      On est bien d’accord que « font-size: 1.4rem » en base 10 et « font-size: 0.875rem » en base 16 est plutôt pas mal équivalent sur le principe, non ?
      L’argument est donc que si l’utilisateur change sa font-size par défaut, alors peut-être que les proportions risquent d’être faussées (de 1px ?) au final ?

      Bah, à choisir entre :
      – écrire ou lire du CSS tel que « font-size: 1.4rem » et comprendre immédiatement que cela vaut 14px
      – écrire ou lire « font-size: 0.875rem » afin d’être systématiquement au pixel près,en prévoyant des cas hypothétiques où l’utilisateur va modifier ses préférences et que cela va éventuellement changer 1px quelque part

      … Je préfère le 1er choix 😉

      1. Ok. Désolé pour les énormes fautes de frappe et le Franglais. Je ne me suis pas relu. 😦
        Oui, on est d’accord pour l’équivalence.

        En d’autre mots. La souplesse avec la base 16. C’est que je ne me sens pas obligé de faire le calcul précis d’un em héritant de l’em d’un parent. Je parts sur une base 1em/16px pour le contenu principal (<main>) et ajuste avec des multiples de 0.625 em uniquement. Les tailles variant généralement de 14 à 24 px. Même si je tombes sur une valeur comme 18.4px au lieu de 18px. C’est pas grave. L’important c’est que ma valeur sub-pixel s’arrondisse correctement. J’utilises donc une seule table de référence px -> em sur la base 16 sans avoir à priori besoin de faire des calculs supplémentaires, pour un élément em dans un élément em. Dans ce sens la, ce n’est pas si pénible que ça. Où tous au moins, j’évite le pénible, sans dommages. 🙂 Par contre, ce n’est pas quelque chose qui serait permissible avec une base 10.
        Le soucis d’une démarche basée uniquement sur les « rem », c’est de se restreindre à un mode de travail complètement différent, avec des cas particuliers ou ça ne fonctionnera pas.

        Prenons le cas du contenu <main>. Il est commun pour un site de news, par exemple, d’offrir un choix de « resize » des fontes d’un l’article uniquement avec des signes [+] en [-]. Dans un tel cas, l’usage des « rem » empêche la possibilité d’un zoom dynamique JS isolé sur cette section. Ce type de contexte force à avoir une valeur « rem » relative. En tout cas, c’est une démarche qui m’est à priori jugée plus convenable en CSS pour le contenu principal.

        L’astuce me convient donc très bien pour un <header>, <sidebar> ou <footer>

        Mais je me vois pas utiliser des « rem » partout. Au minimum, mon choix serait de repartir sur une base 16 pour <main>. Ou bien d’utiliser une base 10 uniquement pour ces balises.

          1. Merci de ton temps. Il en y 2 autres, pour soucis de compréhension:
            pour le contenu principal ([main])
            et
            repartir sur une base 16 pour [main]
            Aussi, ces commentaires de correction peuvent être effacé…

  8. Cette astuce pour repasser en base 10 est une bidouille. Les outils de l’intégrateur font pourtant le job. Par exemple en syntaxe SCSS :

    // …
    $f12: 0.75em;
    $f13: 0.8125em;
    $f14: 0.875em;
    $f15: 0.9375em;
    $f16: 1em;
    $f17: 1.0625em;
    $f18: 1.125em;
    $f19: 1.1875em;
    $f20: 1.25em;
    // …

    Ça prend cinq minutes de définir ces variables dans toutes les tailles qu’on veut à l’aide d’un tableur.

    1. @Paleo

      C’est difficile de définir ce qu’est une « bidouille » en CSS 😉
      Ce que je sais, c’est que :
      – positionner à l’aide de float est une grosse bidouille
      – choisir * {box-sizing: border-box} est une bidouille
      – utiliser des transitions / animations CSS, donc des modules qui ne sont pas (encore) des recommandations, est une bidouille

      Bref, j’utilise également Sass, les variables et les em, mais… c’est vraiment très loin d’être suffisant pour moi. À moins que nous n’ayons pas du tout le même type de projets, ni les mêmes types de besoins, ce qui est probable.

      Dans une intégration modulaire (« à la BEM »), chaque objet se doit d’être autonome et ne pas subir son environnement et sa structure.

      Je prends un exemple concret simple : j’ai un module de « bouton » dont l’un des aspects est d’avoir une taille de police de 14 pixels ($f14 chez toi, j’imagine).
      À présent, je dois inclure ce module dans divers environnements que je ne maîtrise pas forcément, disons :
      – un conteneur dont la taille de police générale est de 16px ($f16)
      – mais aussi dans un conteneur dont la taille de police générale est de 18px ($f18)
      – pire, dans un conteneur de saisie « tinyMCE » où le rédacteur de contenu peut choisir lui-même la taille de police
      – pire, dans une iframe

      Comment gères-tu ce genre de cas pour ce module et pour tous les autres que nous retrouvons un peu partout ?

      (indice, avec ma « bidouille », j’écris .module {font-size: 1.4rem;})

      Le problème de tes variables est qu’elles ne correspondent pas forcément à la réalité selon le contexte où elles sont appliquées : si on devine que $f14: 0.875em; correspond à une taille de 14 pixels, cela ne vaut que dans un environnement où le parent vaut 16 pixels. C’est donc très volatile et trompeur.

      1. Il faudrait en effet utiliser « rem » et non « em » pour définir les variables, ce qui pourra être fait lorsque IE8 sera abandonné. C’est d’ailleurs un avantage des variables : réactualiser une base de code CSS existante, sur le point précis des font-size, consiste juste à modifier les variables.

  9. Ce vieux débat m’exaspère..

    Cette technique prêtant respecter le choix de la taille de texte par défaut de l’utilisateur, mais non seulement elle ne le respecte pas, mais en pratique elle empêche les utilisateurs de changer cette taille !

    Avez-vous déjà changé la taille de texte par défaut à 12px puis tenté de surfer sur le web ?

    C’est impraticable ! Car tous ces sites qui prétendent me respecter m’affiche une taille de 12px * 62.5% * 1.4em = 10.5px ! La moitié du web devient illisible !

    Où est le respect ? J’ai demandé du 12px moi !

    « Oui, je prend en compte ton choix, mais comme ton choix est mauvais je le corrige pour coller à ma maquette. »

    Donc tu ne respectes pas mon choix.

    « Heu oui mais 16px par défaut c’est trop gros. Sur la maquette, c’est… »

    Non. Soit on respecte l’utilisateur et on utilise une taille à 100% du choix de l’utilisateur, soit on respecte la maquette et on utilise des px.

    « Quoi ? Des pixels ? Mais non, faut pas, c’est pêché ! C’est figé et ça ne respecte pas le choix de l’utilisateur ! »

    Ce que tu fais non plus. Arrête de faire semblant s.t.p.

    « Oui, mais… »

    Shhh…

    2. Si j’aime vraiment (vraiment !) l’argument de laisser la fonte de base à 100% sans jamais y toucher (même si ça fait fi des contraintes métier/respect du design demandé par le graphiste, etc.), je trouve que l’argument « soit on respecte la maquette et on utilise des px » est malhonnête =>

      Non, ça ne se résume pas à « choix A »/ »choix B », en fait c’est « compromis C » => on respecte la maquette (contraintes design/métier/toussa) en PERMETTANT quand même de zoomer/adapter/respecter l’intention de l’utilisateur/périphérique.

      Et actuellement, en pratique, j’interprète le changement de taille de fonte ainsi => en mettant une taille de fonte par défaut, tu demandes que ta taille « par défaut » soit à 12px (autrement dit tu la diminues), pas qu’elle soit FORCÉE à 12 px (il y a d’autres méthodes pour l’obtenir ceci dit, styles utilisateurs, extensions genre NoSquintPlus, zoom texte, etc.).
      Après, on peut ergoter des jours sur cette interprétation : respecter l’intention de l’utilisateur/ respecter les préférences utilisateurs.

      De plus, l’utilisateur qui fait sciemment le choix de diminuer la taille de fonte par défaut… doit quand même assumer que tout diminue (idem pour l’agrandissement). 🙂
      Mettre à 12px et se plaindre que c’est trop petit (surtout que la plupart des navigateurs bloquent en-dessous de cette taille => texte à 10px remis à 12px dans Firefox par exemple), c’est un poil fort de café à mon avis 🙂

      Dans l’absolu oui… mais le monde n’est pas absolu.

    1. Mmh non.
      Je pense qu’il ne faut pas faire un « html { font-size: .625em; } body { font-size: 1.4em; } » et laisser plutôt le préprocesseur calculer les valeurs de rem qui correspondent à la base 10.

      Aujourd’hui vous faites ça et demain vos composants externes (TinyMCE ou autre), après un upgrade qui se voulait mineur, ne marchera plus. Il est naturel d’anticiper des « rem » à 16 pixels et de se baser dessus puisque tous les navigateurs le font. Aujourd’hui on s’arrange avec des « em » par souci de compatibilité (et la double correction sur « html/body » laisse les « em » normaux donc ça marche). Et puis un beau jour l’équipe d’un composant externe abandonne la compatibilité IE8, passe au « rem », et ce qui devait être transparent ne l’est pas parce que le « rem » a été manipulé.

      Et puis la base 16 est plus élégante. :p

      1. « Aujourd’hui on s’arrange avec des « em » par souci de compatibilité »
        –> Tu veux dire que tu ferais plutôt ça ? « html { font-size: .625em; } body { font-size: 1.4rem; } »
        C’est exactement la même chose.
        Pour moi qui ait abandonné IE8 depuis un bail, ça ne change rien du tout d’écrire « em » ou « rem » sur body.

      2. @raphael : Non. Je veux dire qu’il vaut mieux ne pas manipuler les « font-size » sur « html » et « body ». J’utiliserai des variables du préprocesseur CSS définies en REM :

        // …
        $f12: 0.75rem;
        $f13: 0.8125rem;
        $f14: 0.875rem;
        $f15: 0.9375rem;
        $f16: 1rem;
        $f17: 1.0625rem;
        $f18: 1.125rem;
        $f19: 1.1875rem;
        $f20: 1.25rem;
        // …

        En revanche, je suis étonné. Quelle est la compatibilité minimale que vous demandent vos clients ? IE10 ? Pour quel genre de projet ?

        1. Ah oui je comprends mieux en effet.

          Notre support navigateur depuis cette année commence à IE10 pour tous nos projets (soit 97% de la population en Europe), même si le contenu doit rester accessible en deça.
          L’an passé nous acceptions encore IE9, et l’an prochain on débutera à IE11.

  11. Bel article qui résume déjà une pratique mise en place sur certains projets chez nous.
    En revanche, tu ne parles pas de l’utilisation de REM pour dimensionner des contenus ?

    Quid du passage au full REM (sans utiliser de px dans tes feuilles de styles) ? Bonne idée, mauvaise idée ? Savoir que peu importe la taille de font-size définie par l’utilisateur, ton composant sera toujours proportionnel (niveau taille et taille de police), ça peu faire envie

    1. Utiliser des rem ou em pour tout ce qui a un rapport avec la taille de la police me semble être une très bonne idée (donc font-size, padding, éventuellement margin).
      Par contre pour des tailles de boîtes, ça se discute. Certains projets sont construits autour des contenus et d’autres non.
      Ce n’est pas forcément un avantage d’avoir des boîtes proportionnelles à la taille de police des contenus : en s’agrandissant chez un utilisateur mal voyant, la boîte va déborder du viewport et poser des problèmes.
      Idem pour une taille de bordure, je ne suis pas fan de l’exprimer en unités relatives.

Les commentaires sont fermés.