Histoires de pourcentages et de calcul arrondi

élucubrations XHTML, CSS
et Standards web

Recherche par mot-clés

CSS · XHTML · Standards W3C · Webdesign · Accessibilité · Référencement · JavaScript · PHP · Humour

AlsaQuiz

A retenir

Syndication

Rédacteurs du blog

Partenaires

Poster

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 :

Sur Le Coin des Experts :

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.

Sur WebDesignGroup (au sujet des frames) :

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.

Par Raphael GOETTER - dimanche 9 janvier 2005 à 17:08

Astuces - #109 - Lu 11737 fois - Intérêt du billet: 1.56(9) - Fil RSS

Trackbacks

Aucun trackback pour le moment.

Les trackbacks pour ce billet sont fermés.

Evaluez ce billet

Commentaires

Le dimanche 9 janvier 2005 à 17:46, par Groumphy :: #

... ... 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é...

Le dimanche 9 janvier 2005 à 17:58, par Raphael :: site :: #

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

Le dimanche 9 janvier 2005 à 18:33, par pablo :: #

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.

Le dimanche 9 janvier 2005 à 18:43, par Piou2fois :: site :: #

En fait il existe une autre chose pour laquelle IE semble plus logique de Firefox

massart.guillaume.free.fr...

Je n'ai pas eu la possibilité de tester sous Safari ou autre

Le dimanche 9 janvier 2005 à 18:51, par Raphael :: site :: #

@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)

Le dimanche 9 janvier 2005 à 18:56, par Daniel :: site :: #

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 dimanche 9 janvier 2005 à 20:54, par Olivier :: site :: #

"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

Le dimanche 9 janvier 2005 à 22:02, par Guillink :: #

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.

Le lundi 10 janvier 2005 à 00:02, par Olivier :: site :: #

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.

Le lundi 10 janvier 2005 à 20:32, par [ NikO ] :: site :: #

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 jeudi 20 janvier 2005 à 18:05, par Nico :: #

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.

Le jeudi 3 février 2005 à 18:54, par sarl :: site :: #

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.