Histoires de pourcentages et de calcul arrondi

Actualité

Publié par le , mis à jour le (22217 lectures)

On trouve parfois, sur les forums, des sujets et des discussions bien intéressantes. C'est une excellente source d'information... surtout lorsqu'on tombe sur des différences d'interprétation entre les navigateurs qui nous avaient échappées jusqu'alors.

Jusqu'à présent, la principale différence d'affichage entre les navigateurs était expliquée par le Modèle de boîte, décrit par Openweb et où une solution est proposée sur cet article.

Récemment, sur le Forum dédié aux Standards et CSS, un sujet a légèrement dévié sur une petite expérience intéressante qui tendrait à montrer qu'il existe une autre différence d'appréciation entre les navigateurs et qui s'appliquerait aux tailles en pourcentage. Je mets tout cela au conditionnel car aucune source officielle ne confirme encore la véracité des conclusions qui sont faites ici.

Le problème ouvert sur le forum traite d'une mise en page avec des éléments qui passent à la ligne alors que le total de leurs largeurs cumulées est inférieur à la largeur de leur conteneur. C'est en général un problème classique de modèle de boîte, sauf que ce n'est pas le cas ici.

En fait, le conteneur (menu) a une taille fixée à 100% (ou 511px). Les éléments internes (liens) ont une largeur telle que leur total fait 100% également (pas de marges, ni bordures ni padding).
Or le dernier élément passe à la ligne sous Internet Explorer, et reste sagement à côté des autres dans Firefox. En fait, après tests, il passe à la ligne dès que le total des éléments dépasse 99%.

Une petite expérience réalisée par FlorentG tend à montrer qu'il existe bien une différence entre les navigateurs dans le calcul des arrondis des pourcentages :

  • Internet Explorer fait un vrai arrondi mathématique (si 33% correspondrait à 19.7px, alors IE considère la valeur comme étant 20px)
  • Mozilla Firefox se contente simplement de supprimer la partie décimale (si 33% correspondrait à 19.7px, alors FF considère la valeur comme étant 19px)

Dans le cas exposé sur le forum, les différence de calcul arrondi font que le total calculé par Internet Explorer est de 512px, ce qui dépasse du conteneur dont la taille est de 511px. Le dernier élément du menu est défini à 16%, soit 81.76px (arrondi à 82 sous IE et 81 sous FF).

Cette différence dans le calcul arrondi des pourcentages (qui s'applique d'ailleurs également aux unités en "em") pourrait expliquer certains problèmes courants de débordements dans les designs fluides.

Je n'ai malheureusement trouvé que très peu de sources sur cette différence de calcul à part les deux liens et pistes suivantes :

Il est clair que seul IE5-windows et NN4.7-unix (dans notre enquête) se conforment à peu près à cette règle. On a l'impression que IE5-mac applique plutôt une règle d'arrondi à l'entier immédiatement inférieur. Surtout on notera le comportement nettement aberrant de NN4.7-mac ou windows, pour qui 100% donne une taille plus grande que la taille par défaut (jusqu'à 3 px de plus !!!), ce qui obligera généralement à prévoir des feuilles de style séparées, l'une pour NN4x et l'autre pour les autres navigateurs.

9.12. Pourquoi mes cadres ne font pas exactement la taille que j'ai demandé?

Netscape Navigator semble convertir en pourcentages entiers les dimensions de cadre exprimées en pixels, et utiliser ces pourcentages pour disposer les cadres. Ainsi, les cadres avec des dimensions exprimées en pixels apparaitront avec une taille légérement différente que celle spécifiée dans le plan de découpage. L'erreur d'arrondie dépendra de la taille exacte de la fenêtre du navigateur.

De surcroît, en interne, Netscape semble stocker la conversion des dimensions en pourcentage, plutôt que les tailles en pixels. Donc, quand une fenêtre est redimensionnée, les cadres sont redessinés en se basant sur les anciens pourcentages. Ceci peut aggraver davantage l'erreur d'arrondi.

Il n'y aucune façon d'empêcher ce comportement. Pour s'en accomoder, vous devez construire un site qui s'adapte aux variations de la taille des cadres. Il s'agit d'une situation supplémenantaire où il est bien d'être capable de s'adapter aux variations.

Merci à tous les intervenants sur la discussion du forum citée.

EDIT : merci à HoPHP pour avoir trouvé la source de ce bug. Il semblerait donc que ce soit bien un bug ("Tracking Bug" numéro 134942) de Mozilla Firefox, selon Bugzilla.

Commentaires

... ... J'en reste pantois ... ...
Jusqu'où allez vous !!

Dois-t'on en conclure dans la précipitation que pour "une fois" I.E. arrondis dans les normes en sachant que le principe est d'arrondir à la valeur supérieur si la valeur après la virgule est supérieur à 5 et inférieur si égale ou inférieure à 5 ?

J'ai fais aussi les recherches et j'ai rien trouvé là dessus.
Voyez m'en navré...

Cela dépend si respecter l'arrondi mathématique est préférable ou non.
Dans ce cas, le résultat est que le total arrondi est plus grand que l'espace disponible, ce qui n'est pas logique non-plus ;)

J'avais eu ce problème avec deux bloc en float:left avec une largeur de 50% (par rapport à la largeur totale du viewport).
Finalement, j'avais mis le 2ème à 49.9% et ça marchait nickel.

Le pire, c'est que je n'avais pas remarqué tout de suite, car ça ne foirait pas si la largeur du viewport était paire.

@Piou2fois : "En fait il existe une autre chose pour laquelle IE semble plus logique de Firefox"
--> dans ton cas de stylage de la balise <html>, il faut également prendre en compte le doctype : en DD HTML, le conteneur global est <body> et non <html>, alors qu'en DD XHTML, la balise <html> est considérée comme conteneur globale (donc stylable)

En fait, j'avais lu cela il y a quelque temps sur www.autisticcuckoo.net/ar...

(citation)Voici un bon conseil : ne spécifiez pas les pourcentages de façon à ce qu'ils fassent 100% exactement (comme 60/40 ou 25/50/25). La moindre erreur d'arrondi déplacerai la colonne la plus à droite sous les autres. Utilisez plutôt 60/39 ou 25/49/25 pour plus de sécurité.(/citation)

"le principe est d'arrondir à la valeur supérieur si la valeur après la virgule est supérieur à 5 et inférieur si égale ou inférieure à 5"
Roo !
le *vrai* principe est d'arrondir à la valeur supérieur si la valeur après la virgule est supérieur ou égale à 5 et inférieur si inférieure strictement à 5

Si l'arrondi mathématique semble plus correct, le tronquage de Firefox me sembled plus prudent

D'ailleurs la preuve est la page d'exemple utilisée sur le forum.

Je suis d'accord avec Guillink
Pour une fois que IE fait un truc correct, ehh ben il aurait mieux valu qu'il s'abstienne :D Car en production, c'est la solution de la moindre largeur qui est la plus efficace. Enfin tout ceci dépend aussi des conditions d'utilisation.

Je me suis de mon coté rendu compte que lorsque j'utilisais des padding:0.3em; cela posait des problémes dans ie, qui parfois me faisait disparaitre des borders ( par exemple sur des li), à cause de ces calculs, j'ai résolu le probléme ne mettant 0.25 ... Allez savoir pourquoi ...
Un des pires bug de ie, c'est sa maniere de gérér les a{display:block;} dans des li. Si dans votre code source, vous faites des passages à la ligne des li. Vous pouvez être certains d'avoir des sauts de lignes entre chaque li.

Le problème vient uniquement des écrans, dont les pixels forment un ensemble discret.
Lorsque l'on pourra couper un pixel en deux, en trois, en l'infini, on aura la solution...

Perso, mon site web fait 407*Pi x Sqrt( 589824 ) et ne s'affiche correctement sous aucun navigateur, étrange.

Non ?

Sérieusement, je pense qu'encore une fois, Firefox est plus "logique" que IE en empêchant que la page n'explose.

Il y a longtemps que j'avais remarqué ce problème comme beaucoup des commentateurs précédents.
La variation de la largeur de la fenêtre (avec la souris) permet de voir le phénomène se produire avec des blocs de Float qui se positionnent correctement dans certaines plages de largeur et passent les unes en dessous des autres pour des valeurs de largeur de fenêtres particulières.

Commentaires clos