28172 sujets

CSS et mise en forme, CSS3

Pourcentages et calcul (arrondi) différent selon le navigateur

Pages :
Salut,

Je souhaite obtenir un menu horizontal composé d'une liste de liens; que ce menu occupe 100% de la largeur, quel que soit l'état de ses éléments.
Mon pb est le suivant :
J'ai mis la largeur du menu à 100% de la page, jusque là tout va bien. Le menu a un fond gris clair, et les éléments deviennent blanc sur bleu au survol. Or, le dernier élément doit occuper toute la largeur restante si on ne veut pas voir apparaître une petite bordure grise sur sa droite.
Si je mets la largeur du dernier élément à 20%, ça marche impeccable sous Firefox, mais sous IE, il renvoie à la ligne dès que la somme des éléments atteint 99.8% apparemment.
Quelqu'un saurait comment résoudre ce schmurz svp ?
Merci

Code HTML :

<ul>
	<li><a href="#">Accueil</a></li>
	<li><a href="#">Section 1</a></li>
	<li><a href="#">Section 2</a></li>
	<li><a href="#">Section 3</a></li>
	<li><a href="#">Section 4</a></li>
	<li class="last"><a href="#">Section 5</a></li>
</ul>

Code CSS :

body
{
	padding : 0;
	margin : 0;
}
ul, li, a
{
	padding : 0;
	margin : 0;
	float : left;
}
ul
{
	list-style-type : none;
	background : #eee;
	border : 2px solid #ddd;
	border-width : 2px 0;
	width : 100%;
}

li
{
	display : inline;
	width : 16%;
}
li.last
{
	width : 19.8%;
}
a
{
	text-decoration : none;
	width : 100%;
	text-align : center;
}
a:hover
{
	color : #fff;
	background : #00f;
}
Moi il occupe bien les 100% avec ton code tel quel:
upload/128-Capture-4.png
Dans ta page il y a bien un doctype correct que IE ne se mette pas Quirks mode?
Le doctype est bon, et on n'est pas en QuirksMode.
Si tu regardes bien mon code, tu verras que c'est justement la version pour IE : la somme des largeurs fait 99.8%, pas 100%. Si tu mets 20% à la largeur du dernier li (et à moins que Murphy ait décidé de me pourrir l'existence), tu devrais avoir un retour de div à la ligne.
Je crains qu'il n'y ait pas grand chose à faire. Personnellement, je laisse toujours un peu de marge quand je met des %, ça arrive lors de problème d'approximation que le calcul fait dépasser les éléments. Par exemple, si ta fenêtre fait 100 pixels, et que tes éléments ont une largeur de 33%, ils prendront du coup 33.333333 pixels Smiley eek . J'me demande du coup si explorer n'arrondit pas ça à 34 pixels, faut essayer...
Bon, j'ai fait un test, donc j'ai copié ton code source, et j'ai regardé deux cas différents : un où ça passe, et un où ça passe pas.
Dans le cas où ça passait, la fenêtre faisait 521 pixels de larges. Là où ça passait pas, 511 pixels. Voici mes calculs :

521px

16% -> 83.36px (arrondi à 83)
20% -> 104.2px (arrondi à 104)

83 * 5 + 104 = 519 -> Ok

511px

16% -> 81.76px (arrondi à 82 sous IE, 81 sous FF)
20% -> 102.2px (arrondi à 102)

82 * 5 + 102 = 512 -> Pas bon, le dernier déborde donc

En mesurant, on retrouve ces valeurs, donc FF supprime bêtement la partie flottante, alors qu'IE fait un vrai arrondi, mais du coup y'a des cas où ça déborde.
Administrateur
Tiens, voilà qui pourrait être intéressant si c'est démontré.
Ça expliquerait certains problèmes d'affichages qui ne seraient pas dûs aux Modèle de Boîtes.
A garder au chaud et à tester. Il faudrait savoir s'il s'agit d'un ""bug"" de FF déjà identifié et reconnu.
C'est une piste interessante, de toutes les manières il peut exister 1 pixel et pas 0,4 pixels ou 1,8 pixels comme le pixel est l'unité de base, on ne peut pas afficher des parties d'un pixel, d'où des arrondissements au pixel supérieur ou inférieur.
Administrateur
Igor a écrit :
C'est une piste interessante, de toutes les manières il peut exister 1 pixel et pas 0,4 pixels ou 1,8 pixels comme le pixel est l'unité de base, on ne peut pas afficher des parties d'un pixel, d'où des arrondissements au pixel supérieur ou inférieur.

Oui mais ici il s'agit bien là de pixels entiers.
L'arrondi du pourcentage, selon le navigateur, tombe sur une valeur différente (arrondi au pixel supérieur ou inférieur).

Un pourcentage qui correspondrait à 1.8px devient 1px sur FF et 2px sur IE.
La page test que j'ai faite ne me donne aucun retour à la ligne dans IE6 même avec li.last {width: 20%;}

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">	
<html lang="fr-ca" xml:lang="fr-ca" xmlns="http://www.w3.org/1999/xhtml">
 <head>
  <title></title>
  <meta http-equiv="content-type" content="text/html; charset=utf-8" />
  <meta http-equiv="content-style-type" content="text/css" />
  <style type="text/css" media="all">
body { 
   padding: 0; 
   margin: 0; 
}
ul, li, a { 
   padding: 0; 
   margin: 0; 
   float: left; 
}
ul { 
   list-style-type: none; 
   background: #eee; 
   border: 2px solid #ddd; 
   border-width: 2px 0; 
   width: 100%; 
}
li { 
   display: inline; 
   width: 16%; 
}
li.last { 
   width: 20%; 
}
a { 
   text-decoration: none; 
   width: 100%; 
   text-align: center; 
}
a:hover { 
   color: #fff; 
   background: #00f; 
}
  </style>
 </head>
 <body>
  <ul>
   <li><a href="#">Accueil</a></li>
   <li><a href="#">Section 1</a></li>
   <li><a href="#">Section 2</a></li>
   <li><a href="#">Section 3</a></li>
   <li><a href="#">Section 4</a></li>
   <li class="last"><a href="#">Section 5</a></li>
  </ul>
 </body>
</html>

Oups, je viens de comprendre. C'est en redimensionnant la fenêtre que le problème est intermittant. Ça confirmerait donc la théorie de FlorentG.
Modifié le 07 Jan 2005 - 13:32
Je viens de faire le même test que Stephan et c'est en redimensionnant parfois la fenêtre que le problème survient.

J'ai refait avec le code à 19.8% et j'ai parfois aussi le même soucis Smiley ohwell
Dans le but d'obtenir des items de largeur identique, j'ai effectué les changements suivants dans le CSS.


li { 
   display: inline; 
   width: 16.6%; 
}
li.last { 
   width: 16.8%; 
}
Administrateur
Des pistes, en attendant d'autres sources :
http://perso.wanadoo.fr/coin.des.experts/reponses/faq9_39.html
Charles a écrit :
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.


http://www.htmlhelp.com/fr/faq/html/frames.html
a écrit :
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.
Administrateur
Stephan a écrit :


li { 
   display: inline; 
   width: 16.6%; 
}

Théoriquement, ceci ne devrait pas fonctionner puisque les éléments en-ligne ne peuvent pas posséder de dimensions.

La question est de savoir ce qui prime dans ce cas précis : la balise HTML (<li> est bloc) ou le comportement donné par CSS (display inline) ?

Je dirais le deuxième puisque l'on applique un display block aux liens <a> pour qu'ils puissent avoir des dimensions.
Administrateur
Au fait, je me permets de renommer le titre du sujet afin de le retrouver plus facilement par la suite...
Raphael a écrit :
Tiens, voilà qui pourrait être intéressant si c'est démontré.
Ça expliquerait certains problèmes d'affichages qui ne seraient pas dûs aux Modèle de Boîtes.
A garder au chaud et à tester. Il faudrait savoir s'il s'agit d'un ""bug"" de FF déjà identifié et reconnu.


Pour la démonstration, j'ai mesuré la taille des différents <li>, en mettant une couleur de fond alternée. On observe bien la différence d'arrondi entre FF et IE.
Raphael a écrit :

Théoriquement, ceci ne devrait pas fonctionner puisque les éléments en-ligne ne peuvent pas posséder de dimensions.


Et bien, <li> semble échapper à cette règle...
Web Design Group a écrit :

The following elements may also be considered block-level elements since they may contain block-level elements:

* DD - Definition description
* DT - Definition term
* FRAMESET - Frameset
* LI - List item
* TBODY - Table body
* TD - Table data cell
* TFOOT - Table foot
* TH - Table header cell
* THEAD - Table head
* TR - Table row

Source : http://htmlhelp.com/reference/html40/block.html
Stephan a écrit :


Et bien, <li> semble échapper à cette règle...

Source : http://htmlhelp.com/reference/html40/block.html


Comme le dit Raphaël, je pense que dans ce cas la propriété display mise à inline prévaut sur la nature de la balise. Voir définition de width : http://www.w3.org/TR/CSS21/visudet.html#the-width-property

En fait, le style par défaut d'un élément inline définit display en block. Mais si on redéfinit en inline, ça devient un élément inline, donc width et height deviennent inopérants.
Administrateur
Stephan a écrit :


Et bien, <li> semble échapper à cette règle...

Source : http://htmlhelp.com/reference/html40/block.html

Je me suis certainement mal fait comprendre.
Je ne dis pas que <li> n'est pas de structure "bloc", mais simplement que je crois que le fait de la passer en inline via CSS empêche de lui donner des dimensions.

En fait, que <li> soit au départ de type bloc ou autre ne change rien, à partir du moment où tu la transformes en inline via CSS.

D'où l'exemple de la balise <a> :
- elle est inline par défaut (donc ne peut pas avoir de dimensions)
- on peut la transformer en bloc grâce aux CSS (et elle pourra alors avoir des dimensions)

C'est juste l'inverse pour <li> selon moi :
- elle est bloc par défaut
- si tu la transforme en inline via CSS elle ne *devrait* plus pouvoir accepter d'être dimensionnée.

Tu vois ce que je veux dire ?

(désolé pour le Hors Sujet)
Et le seul moyen pour pouvoir donner des dimensions à un élément de type inline, serait de définir sa propriété display à inline-block. Malheureusement, IE ne gère inline-block que pour <span> et <a>. Gecko ne connaît pas du tout inline-block. Ca ne fonctionne que sous Opéra...
Pages :
Sujet clos
Aller à