Avisto

Posted on Jun 10 • Originally published at Medium

CSS : Pourquoi faut-il maîtriser ses unités ? 🇫🇷

#webdev #css #cleancode

Dans l’article précédent, nous avons passé en revue la liste des unités CSS et leurs particularités. Mais au-delà de la théorie, une question persiste : quels sont les véritables bénéfices ? Pourquoi se compliquer la vie avec des px, des em ou des pourcentages, quand on pourrait simplement utiliser des rem de manière transversale ?

❔Raison #1 : Représenter une réalité de la manière la plus exacte possible

Potentiellement le plus évident, mais aussi le plus difficile à observer : le travail des développeurs web ne peut pas s’apparenter uniquement à écrire frénétiquement des lignes de codes. Il s’agit surtout de décrire une réalité avec un langage. Chaque ligne de code représente un comportement de notre interface : dis autrement, chaque propriété utilisée, surtout en CSS, décrit un aspect de cette réalité.

Voici un exemple pour illustrer notre propos. Il nous servira de fil rouge tout au long de cet article :

Ci-dessous, deux boutons :

Un bleu,
Un rose.

Si vous mettez de côté leur différence de couleur, ce sont les mêmes.
Pourtant, taille de l’écran mise à part, voici comment leur taille est expliquée :

Bouton bleu a une hauteur de 48px et du padding latéral de 16px
Bouton rose a une hauteur et une largeur de 100% celle du parent

→ Même résultat, et pourtant les intentions sont très différentes.
Pour le plaisir, ajoutons une autre implémentation :

Vous voulez essayer de deviner cette proposition ? Voici ce que nous obtenons :

Bouton vert à une hauteur et une largeur ajustées à son contenu, avec un padding de 1rem

Cette petite démonstration illustre bien la raison pour laquelle il existe de nombreuses unités.
En effet, ces dernières permettent d’exprimer un besoin de différentes manières :

Le bouton bleu convient pour un design simple, s’il n’est pas nécessaire de le réutiliser par la suite ou de le placer dans un layout complexe.
Le bouton vert répond à une tentative de gestion de changement de taille de police.
Le bouton rose, quant à lui, est conçu pour être utilisé dans des grilles ou des conteneurs flexibles (grid ou flexbox), car c’est le layout qui déterminera sa taille finale.

Sur une maquette classique, l’apparence de ces boutons sera identique. Si leur taille varie selon la page consultée, la maquette indiquera simplement que la taille a changé, sans en préciser la raison.

🧙‍♂️ Ce qu’il faut retenir, c’est que le choix des unités ne doit pas être guidé uniquement par des considérations techniques, mais aussi par des choix de design et de produit.

❔Raison #2 : Développer de (vraies) interfaces responsives

Il y a-t-il une relation de gain direct entre utiliser des unités relatives à la police et réaliser une interface responsive et robuste ? → FAUX

Confusions les plus courantes qui alimentent cette croyance :

La consonance forte entre les termes “responsive” et “relative”.
Le coté “dynamique” : une “unité dynamique” qui pourrait faire penser qu’elle est intéressante pour construire des “pages dynamiques”.
Le fait que terme “relatif” évoque l’adaptabilité et donc, la responsivité.

L’erreur est à la fois sémantique et technique : on confond souvent une unité proportionnelle avec une capacité de mise en page adaptative.

On pourrait en imaginer beaucoup d’autres, mais cela montre bien que le sujet est un terrain fertile pour les fausses bonnes idées.

Il est important de garder en tête que la responsivité d’une page se joue principalement sur ce qu’on appelle le layout [7]. À savoir, l’espace accordé à chaque élément sur une page. Une interface responsive est une interface qui possède des “adaptative layouts”.

Illustration des principes d’adaptative layout

Voici un exemple avec une interface ‘classique’, affichée sur un écran d’ordinateur :

Avec une tablette, le layout change et la présentation des éléments n’est plus la même. Ce n’est pas qu’une question de réduction de taille des éléments :

C’est encore plus flagrant avec une interface mobile :

Que se passe-t-il quand on réduit la taille du navigateur ? La taille des textes est-elle réduite ? les espaces entre les cartes sont-ils plus petits ? L’aspect est-il conservé ?

Vous l’avez compris, l’adaptative layout est pensé pour maximiser la qualité de l’expérience utilisateur sur chaque device.
Write on Medium

En conséquence :

L’agencement du layout et de ses composants va être ajusté.
La disposition des cartes ne sera plus la même et la barre de navigation seras remplacée par un “burger menu”, plus adapté aux smartphones et tablettes.

Il n’est pas question de simplement “tout réduire”.

Pour créer un adaptative layout, nous utilisons des breakpoints :

Ce sont des largeurs personnalisables qui déterminent le comportement de notre mise en page en fonction de la largeur de l’appareil ou de la fenêtre
La plupart des librairies proposent des valeurs de référence (comme par exemple sm, md, lg, etc.)

⚠️ Un conseil : Ne jamais réduire la taille des textes pour gagner de l’espace ! Oui, sur mobile, la taille de police peut se permettre d’être un peu plus petite parce que la distance entre l’écran et l’œil est plus faible. En revanche, ce choix ne doit pas être motivé par un gain de place.

🧙‍♂️ Vous l’aurez compris : ce n’est pas parce que vous utilisez des unités relatives que vous développez une interface responsive. Pour avoir un design responsive, le véritable enjeux de conception se trouve au niveau des layouts.

❔Raison #3 : Gérer l’accessibilité

C’est une problématique essentielle et qui, pourtant, reste souvent mal comprise lorsqu’il s’agit des unités. En grande partie pour des raisons historiques.

Avant 2005, les navigateurs étaient limités techniquement : lors d’un zoom, ils n’étaient pas capables d’agrandir la taille de la police comme le reste du contenu de la page. Cela signifie qu’à cette époque, la seule méthode pour grossir un texte sur un écran était de changer la taille de la police sur l’appareil. Cette taille était alors utilisée comme taille par défaut pour l’entièreté des pages web consultées.

Nous n’entrerons pas ici dans le détail du “C” de CSS, donc nous utiliserons le terme “police par défaut” plutôt que “root”.

Ainsi, avant 2005, le seul moyen de rendre votre site accessible au public malvoyant était d’utiliser des rem, soit l’unité de longueur relative à la taille de la police par défaut. Les font-size de votre application étaient alors modifiées en fonction du choix de l’utilisateur.

Aujourd’hui, les navigateurs ont beaucoup évolué et gèrent très bien le grossissement de la police, même en unité absolue lors d’un pinch-to-zoom.
Press enter or click to view image in full size

⚠️ Le pinch-to-zoom peut dépanner, mais il ne remplace pas une bonne gestion des tailles de texte. Certains utilisateurs modifient uniquement la taille de la police, il faut donc penser à eux pour garantir une accessibilité complète.

Maintenant, supposons que nous ayons exprimé tous nos textes en rem et que la phrase suivante nous semble correcte :

Les textes de mon application sont des multiples de la taille de la police par défaut

Observons le comportement sur nos boutons :

Les 3 boutons ont une font-size de 1.2rem. Si l’utilisateur n’a pas modifié la taille de sa police, cela correspond à 1.2 * 16px = 19.2px.

Nous pouvons d’ores et déjà observer que le bouton vert prend plus de place que ses voisins et que le libellé du bouton rose approche dangereusement des limites de son conteneur.

Maintenant, nous allons modifier la taille de la police de notre navigateur, afin d’observer l’impact sur nos boutons. Pour ce faire, avec Google Chrome, rendez-vous ici :

Paramètres > Apparence > Taille de police

Ci-dessous, nos 3 boutons avec une taille de police « très grande » :

Ci-dessous, nos 3 boutons avec une taille de police « très petite » :

Le bouton vert s’en sort mieux que ses confrères : ce n’est pas parfait, mais les proportions sont respectées. La raison est simple : c’est le seul à utiliser les rem comme taille de texte et d’espace.

Attention toutefois : ce n’est pas magique. S’appuyer sur les rem pour gérer les changements de taille de police par défaut peut rapidement devenir un terrain glissant, voire un véritable marécage.

Si le bouton vert était contenu dans un layout dont les dimensions ne permettaient pas d’accueillir un composant plus gros, alors l’interface aurait dérapé.
À l’inverse, si les boutons avaient des tailles définies en pixels, ce problème ne se poserait pas car leur dimension ne dépendrait pas de la taille de la police.

Pour réussir à combiner la responsivité et les principes d’accessibilité sur la taille des polices, il est nécessaire de recourir à une conception minutieuse, qui concerne l’ensemble de l’équipe et pas uniquement les designers. C’est aussi une question de budget, qu’il s’agisse de la taille de l’équipe ou des moyens alloués.

❔Raison #4 : Se simplifier les calculs

Vous commencez peut-être à sentir une certaine critique envers l’utilisation des em et des rem. Vous avez raison, ils augmentent très souvent la complexité déjà bien trop présente du CSS.

En effet, si votre site ne bénéficie pas d’un design qui prend en compte la modification des tailles de police via les paramètres, alors il n’y a aucune raison d’écrire vos valeurs en multiple de 16.

En réalité, en dehors du côté “dessin”, il y a une autre raison qui pousse les gens à ne pas aimer le CSS : sa complexité de relecture.

Il est très facile d’override une propriété par mégarde, sans s’en rendre compte. La fonctionnalité de cascade est à double tranchant. Il arrive aussi que le css soit écrit dans un fichier et s’applique à un autre endroit de l’application. C’est une complexité qui n’apporte aucun plaisir ni mérite. Vraiment, relire du CSS, c’est comme défaire un gros paquet de nœuds, c’est long, compliqué et surtout pas très stimulant.

Cela explique en grande partie la popularité de l’utility first avec Tailwind.

Alors, ce n’est donc vraiment pas l’endroit òu ajouter de la complexité sans raison.

La marge extérieure droite mesure ?2.3 rem? et ma bordure ?0.2rem? d’épaisseur.

Dans ce cas la, on se concentre uniquement sur le résultat en espérant qu’il n’y ait aucun bug, puisque de toute manière, on ne comprend pas ce qui a été écrit.
On obtient alors du code “mort”, que personne n’ose modifier et supprimer puisque personne ne sait concrètement ce qu’il fait. Sur des projets qui vivent pendant plusieurs années, cela amène forcément à tout reprendre un jour.

De plus, sur un projet dénué de réflexion sur le sujet, on verra des rems et em imbriqués avec des tailles de police qui changent sans que personne ne l’ai prévu. Ajouter à cela la gestion des breakpoint et plus personne n’est en mesure de prévoir la tailles des éléments affichés à l’écran. Très vite, votre projet devient une école de magie : on ne code plus, on lance des sorts !

Vous l’aurez compris, connaître les unités, c’est bien, mais savoir les choisir correctement, c’est une autre mission.

Le prochain article ne parlera plus d’unité, vous maitrisez maintenant. Mais nous nous intéresserons à l’architecture CSS minimum pour des projets concrets.