Pourquoi 16px est la taille de police de base par défaut

16px est la taille de police par défaut dans les principaux navigateurs parce qu’elle affiche le texte courant à une taille confortable pour les distances de lecture typiques à l’écran, et elle tient ce rôle depuis les débuts de l’ère CSS. La valeur par défaut compte au-delà de l’histoire : les utilisateurs qui ont besoin d’un texte plus grand la modifient dans les réglages de leur navigateur, et le dimensionnement basé sur rem hérite de leur choix — ainsi un système typographique ancré sur la valeur par défaut reste accessible à mesure qu’il change d’échelle.

Cet article explique d’où vient ce nombre, ce que la base contrôle réellement, et quand une base différente est le meilleur choix. Il fait partie de notre guide des échelles typographiques.

D’où vient la valeur par défaut de 16px ?

Les premiers navigateurs graphiques étaient livrés avec une taille de texte par défaut « medium », qui s’affichait à 16px, et CSS a conservé cette convention. Ce nombre est moins arbitraire qu’il n’y paraît. CSS suppose une résolution nominale de 96 pixels par pouce, ce qui fait de 16px l’équivalent de 12 points — une taille de texte courant sur laquelle la typographie d’imprimerie s’était fixée bien avant les écrans. L’intention s’est perpétuée : à une distance de lecture d’écran de bureau typique, un texte de 16px occupe à peu près le même angle visuel que le texte courant imprimé à distance de lecture. La valeur par défaut perdure parce qu’elle vise la taille à laquelle les yeux des lecteurs sont déjà habitués — non parce que le nombre lui-même a quelque chose de spécial.

La documentation MDN sur font-size couvre les mécanismes : les tailles par mot-clé comme medium, les unités relatives em et rem, et la façon dont elles se résolvent par rapport aux tailles héritées et à la taille racine.

Pourquoi respecter la valeur par défaut est-il important pour l’accessibilité ?

Parce que la valeur par défaut est un réglage utilisateur, pas une constante. Les personnes malvoyantes, ou simplement celles qui passent de longues journées devant un écran, augmentent la taille de police par défaut de leur navigateur — et chaque taille déclarée en rem s’ajuste à ce choix, puisque rem se résout par rapport à la taille de police de l’élément racine. Une feuille de style qui fixe la racine en pixels fixes écarte silencieusement la préférence de l’utilisateur ; celle qui laisse la racine intacte et dimensionne en rem la propage à toute la hiérarchie.

C’est l’argument le plus fort pour traiter 16px comme un ancrage plutôt que comme une décoration : construisez l’échelle autour de la valeur par défaut, exprimez-la en unités relatives, et la préférence de 20px de l’utilisateur reproduit toute votre hiérarchie 25 % plus grande — proportions intactes.

Que contrôle réellement la base dans une échelle typographique ?

Dans une échelle modulaire, la base n’est pas une taille parmi d’autres — c’est l’origine à partir de laquelle chaque autre valeur est calculée. Scale Composer génère les tailles avec size = base × ratio^(i/notes), dérive les pas d’espacement à partir de la même base, du même ratio et du même nombre de notes, et définit une unité de ligne de base égale à base/2. Changez la base et tout le système évolue proportionnellement :

(Valeurs indiquées avant arrondi.) Chaque taille se décale du même 12,5 %, et les relations entre les niveaux restent intactes — ce qui est tout l’intérêt de tout dériver d’un seul ancrage.

Ouvrez l’anatomie d’une base de 16px dans Scale Composer — la vue est centrée sur le pas 0 et montre les tailles au-dessus et en dessous, ainsi que la ligne de base de 8px produite par la base.

Faut-il régler html à 62,5 % pour simplifier les calculs en rem ?

L’astuce — html { font-size: 62.5% } pour que 1rem égale 10px — échange une petite commodité arithmétique contre une friction structurelle, et de nombreux praticiens ont convergé pour l’éviter. Trois raisons reviennent systématiquement :

1. Les media queries ne suivent pas. em et rem dans les media queries se résolvent par rapport à la taille de police initiale du navigateur, pas par rapport à votre surcharge de la racine — vos points de rupture et vos composants finissent donc par fonctionner sur deux valeurs de rem différentes.
2. Le code tiers suppose 16. Les bibliothèques de composants et les widgets intégrés se dimensionnent souvent en rem en partant du principe que 1rem ≈ 16px ; sous 62,5 % ils s’affichent tous plus petits que prévu.
3. La commodité est devenue caduque. Quand une échelle génère les valeurs et les exporte sous forme de design tokens ou de CSS, la conversion mentale rem-vers-px pour laquelle l’astuce existait disparaît en grande partie du flux de travail — le problème qu’elle résolvait n’est plus là où le travail se fait.

Quand 18px est-il une meilleure base ?

Quand le produit est surtout composé de texte. La lecture au long cours — articles, documentation, tout ce qu’une personne lit pendant des minutes plutôt que de le parcourir en quelques secondes — bénéficie d’une taille de texte courant plus grande, et les sites éditoriaux fixent souvent le texte courant entre 18px et 21px. Le lecteur se cale en arrière, les lignes s’allongent, et 16px commence à paraître petit pour la distance.

La décision reste simple parce que la base est un paramètre unique : un produit de lecture démarre l’échelle à 18, un produit mixte ou dense reste à 16 et réserve un pas au-dessus de la base pour les chapôs. Dans les deux cas, le reste du système suit automatiquement.

Déplacez la base et regardez le système suivre

Le rôle d’ancrage est plus facile à ressentir qu’à lire : faites passer la même échelle à une base de 18px — une configuration réglée pour la lecture au long cours — et regardez chaque taille, chaque pas d’espacement et la ligne de base (désormais 9px) évoluer ensemble tandis que les proportions tiennent. Puis revenez à 16 et décidez à quelle distance votre produit est réellement lu.