Traditionnellement, quand on veut partager une largeur en trois portions égales, on écrit width: 33.3333%;. Alors oui, d’accord, à l’époque pré-industrielle nous n’avions pas vraiment le choix. Mais aujourd’hui ?
Les décimales arbitraires
Savez-vous ce qui pêche avec les décimales ? Plusieurs choses, en fait — à commencer par le fait que vous définissez arbitrairement à quelle décimale vous vous arrêtez…
La précision
Et bien oui, forcément : si vous faites 33.33333% × 3, vous n’obtenez pas 100 %. Il vous manque 0.00001 %. Négligeable ? Peut-être.
Les arrondis et la troncature
Mais si je vous rappelle qu’IE tronque systématiquement les valeurs à la deuxième décimale, ça peut commencer à jouer un peu. En effet sur IE 11 il vous manque donc 0.01 % sur votre largeur totale.
Et si je vous rappelle que sur la même valeur, Chrome va arrondir à la treizième décimale ? Plutôt compliqué à anticiper.
Et alors ?
OSEF !
Admettons. On ne vit qu’une fois, après tout…
C’est probablement anecdotique effectivement, puisque dans le pire des cas vous n’aurez qu’un pixel de plus ou de moins. Cependant si ce « détail » vous intrigue, il est plutôt bien détaillé dans cet article d’Alex Kilgour intitulé Browser Rounding and Fractional Pixels.
Personnellement, je me sens un peu sale en laissant traîner des valeurs arbitraires — comme je l’ai déjà évoqué quand je parlais de calcul magique.
La fonction calc
Finis les tours de passe-passe : calc() vous permet d’écrire de manière concise et précise une valeur égale à un tiers.
.⅓ {
width: calc(100% / 3);
}Et voilà.[1]
Compatibilité
Et le top, c’est la compatibilité : tout est au vert depuis IE 9. Voyez plutôt le tableau sur Can I Use?. Les seules tâches qui subsistent concernent des navigateurs pour téléphones, pour lesquels on peut raisonnablement supposer qu’un affichage d’un tiers de la largeur ne sera pas utile.
Alors, demeure-t-il une raison valable d’utiliser des valeurs décimales arbitraires, selon vous ?
Au fait, si dans le bout de code le .⅓ vous choque, sachez que ça fonctionne — Kitty Giraudel a même déterré une expérience de Mathias Bynens à ce propos : https://mothereff.in/css-escapes#0%E2%85%93 — et que ça me paraît un excellent nom de classe pour exprimer un tiers. Pas vous ? ↩︎
J’ai un vague souvenir que
calc()dépendait de l’activation ou non du JavaScript dans le navigateur. Mais c’est peut-être un très ancien souvenir, et peut-être que maintenant ce n’est plus lié…?Hum je n’ai jamais entendu parler de ça, en tout cas. Intrigante remarque, je vais creuser un peu. 🙂
Bonjour Gaël,
Ton article me rappelle beaucoup celui de Divya Manian : https://nimbupani.com/using-decimal-percentage-values-in-responsive-design.html
Même si la fonction
calc()est plus précise, elle n’empêche pas les problèmes dans IE / Edge concernant les arrondis… ex. : https://s.codepen.io/7studio/debug/BWbBwM/vWkRwnPZZOXMJe n’ai pas de raison valable mais j’utilise souvent les valeurs décimales arbitraires (désolé) mais avec stylelint et sa règle « number-max-precision » comme garde-fou. Et lorsque j’utilise
calc(), postcss-calc va remplacer tous mes calculs dans les styles finaux ^^Ah attention, je demande pour de vrai si vous avez de bonnes raisons de ne pas utiliser
calc(). S’il y a encore des cas où ça merde, ça m’intéresse. 🙂Huhu, certains navigateurs sous webkit avaient du mal avec les arrondis, en rétrécissant une fenêtre avec des éléments posés côte à côte, tu les voyais rétrécir en fonction… sauf de temps en temps, ça s’agrandit très légèrement avec un petit saut – je pense que ça se passait justement sur des arrondis foireux.
Alors oui, il y a un cas où calc() me pose encore problème. C’est sur les largeurs de cellules de tableaux dans Firefox (je suis actuellement sur la 55.0.2). Firefox n’a que faire des calc() dans ce cas, quelque soit l’unité de valeur.
J’ignore si le bug est remonté chez Mozilla.