Proposition d'un correctif sur la fonction calc()

[Scriptura]

width: calc(100% * 1 / 4 - 1em - .01px);

Suggestion : pourquoi ne pas faire calculer la largeur prévisible par le pre/post processeur ?

100% * 1 / 4

La fonction calc() n'a ensuite plus qu'à enlever le - 1em :

width: calc(25% - 1em);

Je vois deux avantages à cette solution :

• 1. Le moins important : ça soulage un peu le calcul pour le navigateur (enfin bon, c'est pour chipoter...)
• 2. Mais surtout cela éviterait d'ajouter le correctif du dixième de pixel à enlever ( - .01px), correctif qui si je ne m'abuse a été apporté en solution à l'arrondissement des calculs fait par IE et qui fait "exploser" la grille. Je me trompe ?

[raphaelgoetter]

Merci @Scriptura pour cette proposition.

Avant de l'implémenter, il faudrait vraiment faire quelques tests pour être sûr que le problème du bug évoqué sur IE soit corrigé : #133

[Scriptura]

Justement, si j'en crois la conversation à laquelle tu fais références, il s'agit bien d'un problème d'arrondissement des décimales par IE. Personnellement je ne le savais pas mais je l'avais déduit du comportement de la grille.

En tout les cas, sur mon framework perso, j'ai testé cette solution depuis quelques semaines, avec une mire de grilles imbriquées, et cela n'explose pas sous IE 10-11 à ma connaissance. Mais il faudrait que je teste plus avant car je ne suis qu'un Mac user et je n'ai pas souvent accès à un PC pour tester mes dernières modifications.

Tu es sous Less, moi je tourne avec Sass. Avec Sass donc :

width: calc(#{100% / 12 * 11} - #{$gutter});

Chez moi ça donne ceci :

 width: calc(91.66667% - 1rem);

5 chiffres après la virgule, qui devraient mettre tous les navigateurs d'accord lors des tests.

J'éprouverai ma solution en corsant mon test avec des grilles imbriquées sur trois niveaux : the grids. Dès que j'aurais un PC sous la main...

[Scriptura]

Nop : j'ai testé et ma proposition ne fonctionne pas sous tous les cas de figure. Dommage, sujet à enterrer...

Edit. Peut-être pas finalement : en refaisant mon workflow sous Gulp je viens de m'apercevoir à l'instant que l'on peut régler la précision du calcul des décimales de son préprocesseur (une option que je ne connaissait pas) qui, sous Sass est limité à 5 chiffres après la virgule. Mais pour Less je ne sais pas...

[PhilippeVay]

Il y a round(), bien utile pour les font-size: 1.8282828282em :)

[raphaelgoetter]

Selon moi, quel que soit le nombre de décimales le bug IE reste le même et cela ne changera rien.
IE10-IE11 tronquent la valeur à 2 décimales. Que le nombre fasse 3 décimales ou 5 ou 13 ne devrait rien changer, non ?

Le problème actuel vaut pour les grid-3 qui sont calculées avec un calc(100% / 3). Que le résultat fasse 33.333% ou 33.333333333333%, il sera toujours tronqué à la 2è décimale par IE, donc donnera 33.33% (? )

[Scriptura]

Ok, merci à vous deux.

Voici pour l'instant ma solution, je l'ai testé sur des grilles complexes ; elle semble fonctionner sur tous les browsers mais elle est lié au prépros utilisé, ce qui à mon avis ne plaira pas à Raphaël :

• Sous Sass Ruby : paramétrer une option precision: 2 dans le Task Runner et, dans tous les cas, arrondir les nombres au chiffre inférieur avec la fonction floor() (et surtout pas round() Philippe).
• Sous Stylus : pas de paramétrage global, utiliser là aussi la fonction floor(), mais avec un paramètre supplémentaire pour le choix du nombre de décimales floor(value, 2).

Chez moi c'est OK.

[raphaelgoetter]

Je demeure persuadé que de souhaiter arrondir à 2, 3 ou X décimales est une mauvaise idée.

Cela fonctionnera sans doute sur les cas de figure fréquents, mais sur des très grands écrans le manque de précision dans la valeur finale impliquera forcément un "manque" de pixel sur la dernière colonne (en clair, avec un arrondi de 2 décimales, le total calculé et arrondi puis computed en pixel donnera des résultats tels que 999px et non 1000px).

Pour moi, plus il y a de décimales plus on est sûr d'obtenir systématiquement un total de 100% même sur des surfaces très larges.

[Scriptura]

OK. Attend : je vais tester les mêmes grilles dont j'ai parlé sur de très grandes largeurs (sur Mac on peut étirer les fenêtres des logiciels au-delà de la taille de l'écran) puis je reviens.

[Scriptura]

Bon, c'est fait : il y a effectivement un décalage, léger, sur grandes résolutions. La solution de retirer les 0.01px est meilleure car elle ne provoque aucun décalage visuel. J'adopte cette solution définitivement.

[raphaelgoetter]

Définitivement... En attendant Edge ? :)
Merci pour les tests en tout cas.

[Scriptura]

De rien, je fais les tests pour moi aussi, pour le plaisir de chercher des astuces...

Avec la solution du correctif 0.01px j'ai un exemple de bug sur une grille complexe imbriquée sur 4 niveaux, à 576px de largeur très exactement. Autant dire que c'est extrême comme test et qu'on n'a pas non plus besoin d'une grille imbriquée comme cela tous les jours. Edit : non c'était une erreur : un bug lié à un media queries. Aucun problème en fait...

Et du coup, comme IE arrondit à 2 décimales, j'arrondis moi aussi à 2 décimales, je ne sais pas trop : je me dit que c'est toujours ça de moins à faire calculer en live par la fonction calc()...

A+

[PhilippeVay]

Je demeure persuadé que de souhaiter arrondir à 2, 3 ou X décimales est une mauvaise idée.
Cela fonctionnera sans doute sur les cas de figure fréquents, mais sur des très grands écrans le manque de précision dans la valeur finale
Pour moi, plus il y a de décimales plus on est sûr d'obtenir systématiquement un total de 100% même sur des surfaces très larges.

1 décimale c'est pas assez et 10 c'est forcément trop. Ça se calcule en fait :

• un écran a une taille à 4 chiffres (entre 320 et 4k)
• Si dans la CSS il y a 91.66667% alors tu calcules combien ça fait de px en prenant 91.66666% puis en prenant 91.66668%
• si l'écart est inférieur à un certain seuil, il y a assez de chiffres significatifs