28173 sujets

CSS et mise en forme, CSS3

Bonjour à tous,

Vous avez déjà tous vu le fameux problème des éléments flottants qui ne sont plus pris en compte dans le flux de l'élément parent (et donc dans le calcul de sa hauteur) avec les navigateurs respectant un tant soit peu les CSS. C'est à dire dans ce cas précis :
- navigateurs basés sur Gecko (Firefox)
- Safari
- Opera
- Konqueror
- IE Mac 5
Mais pas avec IE 6.

À force de l'expliquer aux débutants (et un peu moins débutants) qui rencontrent ce problème pour leur site, j'ai eu l'idée d'en faire une page explicative. Elle se trouve par ici :
Éléments flottants qui dépassent de l'élément parent

Alors d'accord, ça fait sûrement doublon avec la faq ( http://forum.alsacreations.com/faq/#item6 ), mais ça a l'avantage de proposer quelque chose de visuel qui permette de faire des tests dans divers navigateurs. Et puis j'avais envie Smiley lol

Le fond de la question : je rencontre deux problèmes de compatibilité.

Problème n°1 :
La première solution, la plus classique (celle du spacer en clear: both;), pose problème avec IE Mac (testé sous IE Mac 5.2). Le deuxième élément flotté est bien flotté à droite, mais passe à la ligne tout de même. Après des tests pour éliminer le risques de collision de blocs (en réduisant le paragraphe à une largeur très faible pour laisser toute la place nécessaire à l'image sans risquer qu'un chevauchement ne provoque un retour à la ligne), je n'ai toujours pas trouvé la source de ce problème.
Cependant, il me rappelle un article de Laurent Denis sur le contexte de formatage de bloc.
http://www.blog-and-blues.org/articles/Float%2C_clear_et_contextes_de_formatage
Mon problème est différent du cas exposé, mais il pourrait y avoir un lien. Sauf que je n'y comprends pas grand chose, et que les histoires de contexte de formatage de blocs, là j'ai un peu de mal.
C'est à peine s'il ne faudrait pas avoir écrit soi-même les divers clients web sur le marché pour savoir comment ils fonctionnent vraiment ! Smiley sweatdrop

Problème n°1 :
La deuxième solution, celle d'utiliser la propriété overflow: auto; sur le bloc parent (ce qui crée un contexte de formatage de bloc... j'ai bon ?), est séduisante. Elle passait très bien lors de mes tests sous Firefox 1.5, Opera, Konqueror, Safari et IE Mac, et sans provoquer de cataclysme dans IE6 Win. Je me suis dit : « C'est dans la poche ! »

Mais non : bug observé avec Firefox 1.0.x (1.0.4 sous Mac OS et 1.0.7 sous Linux) : l'écart entre le deuxième élément flotté et le bloc conteneur fait le triple de la taille attendue (il devrait se limiter à un padding-right de 20px, et il fait 60px). Pas glop.

Tests :
- Le problème ne se pose que pour des blocs en largeur fixe (pixels ou em).
- Le problème ne se pose pas pour des blocs sans largeur fixée.
- Le problème ne se pose pas pour des blocs ayant une largeur en pourcentage de la largeur disponible (widht: 60%; par exemple).
- La position des éléments dans le flux du document n'a aucune influence.
- La présence de texte en début de bloc conteneur (texte en flux, que des éléments de type en-ligne et des caractères) n'a pas d'influence non plus.
- La suppression du padding-right de 20px du bloc conteneur supprime 40px de notre écart. On n'a plus que 20px.
- La suppression du padding-right de 20px et du padding-left de 20px du bloc conteneur réduit l'écart à 0px.
- Les padding en unités relatives (em) posent le même problème.
- On constate aussi que parfois le bug "s'installe" en deux temps. Un premier chargement de la page donne un comportement normal (pas de bug), mais si on recharge la page le bug revient.

En résumé, au lieu d'avoir :
padding-right = padding-right = 20px
On a :
padding-right = (padding-right × 2) + padding-left = 60px
Uniquement pour le padding-right.
Uniquement lorsqu'on a des éléments flottant à droite.

Si quelqu'un sait quelque chose sur ce bug assez surprenant ?
Modifié par mpop (21 Feb 2006 - 19:23)
Bonsoir,

Merci pour ces tests. J'ai visité ta page avec FF 1.06, et effectivement ça ne va pas alors qu'il n'y a aucun problème sous FF 1.5 Smiley ohwell .. Je n'ai jamais rien lu là dessus !

Sinon il y a une autre solution : appliquer un display: table; au bloc parent : comme un tableau, il encadrera tous les éléments flottants, sans les laisser dépasser.
Etant donné que IE ne laisse pas déborder les éléments flottants (toujours pas le cas de IE7beta2 preview), peu importe qu'il ne prenne pas en charge display: table; . IE mac, je ne sais plus s'il réagit comme IEwin.. au pire un petit hack spécial IEmac avec overflow: auto; fera l'affaire.

Evidemment, il faudrait faire attention par exemple à donner une taille (fixe ou pourcentage), sinon avec "display: table", le bloc s'agrandirait en fonction du contenu, comme pour un tableau (à moins qu'il y ait toujours un contenu suffisant).

Enfin, concernant l'ajout d'un élément comme:
<div style="clear:both;"></div>

Netscape n'aime pas s'il n'y a pas une hauteur. Avec ce code, cela n'aurait aucun effet.

(tu as fait une erreur d'inattention ci-dessus en écrivant display: auto; au lieu d'overflow)
Modifié par Alan (14 Feb 2006 - 22:17)
Alan a écrit :
Enfin, concernant l'ajout d'un élément comme:
<div style="clear:both;"></div>

Netscape n'aime pas s'il n'y a pas une hauteur. Avec ce code, cela n'aurait aucun effet.


Tu aurais des précisions sur ce problème ?
C'est vrai que j'ai un peu tendance à oublier Netscape (je n'en ai aucune version sur mon ordinateur personnel, et aucun des ordinateurs de la fac - PC Windows ou Mac - ne l'a d'installé... juste IE, Safari, Firefox, Camino...).
Hop, page mise à jour pour refléter les différents retours que j'ai pu avoir et tests que j'ai pu faire :

http://web.covertprestige.info/test/03-elements-flottants-et-element-parent.html

On y trouve un nouveau bug de Firefox (il faut bien qu'il y en ait tout de même, sinon on finirait par s'emmerder !), qui concerne l'implémentation de display: table;. Ou alors j'ai compris les choses à l'envers et c'est Firefox qui a raison, tandis que Opera et Konqueror ont tort.

PS: euh non, pas un bug, vu que c'est probablement un comportement prévu. Disons plutôt une erreur d'implémentation.
Modifié par mpop (21 Feb 2006 - 19:24)
Merci mpop, c'est une bonne initiative, ça a le mérite de présenter les choses de manière concise. J'en profite pour te confirmer le comportement du display:table en version 1.6a1 (Deer Park alpha2 la bien nommée) de Firefox, ce qui tend effectivement à prouver que c'est comme ça que ça doit fonctionner pour eux.

Smiley smile
Bonjour,

Merci pour avoir relevé cette différence de comportement entre Gecko et les autres avec display: table. A vrai dire je n'avais pas mis un padding suffisant dans mes essais pour voir la différence, et j'avais juste mesuré sur FF...
Ce n'est donc pas une bonne solution, qui compliquerait plutôt les choses.

Sinon, concernant Netscape 7, il y a exactement le même bug que Firefox 1.0x avec overflow: auto; sur l'élément parent.

Concernant
<div style="clear:both;"></div>

Je t'avais dit que ça ne marchait pas pour Netscape 7. En fait c'est aussi le cas sous FIREFOX 1.0x : il faut une hauteur minimum, sinon le clear ne permet pas à l'élément parent d'englober visuellement son contenu flottant.
Mais si on ajoute une height: 1px;, il faudrait ajouter overflow: hidden; à cause de IE, sinon ce dernier ajoute carrément une hauteur de ligne !

j'ai essayé sous Firefox 1.06. Dans ton essai, tu dis que c'est OK pour Firefox 1.0.4. Mais avais-tu essayé simplement avec la <div> vide ?

A+
Modifié par Alan (15 Feb 2006 - 08:52)
Alan a écrit :
j'ai essayé sous Firefox 1.06. Dans ton essai, tu dis que c'est OK pour Firefox 1.0.4. Mais avais-tu essayé simplement avec la <div> vide ?

Effectivement, dans mon test, la div n'est pas vide. Rats!...

...
un peu plus tard
...

Je viens de faire un test minimal (avec une div vide et aucun contenu en dehors du test) et ça passe sans problème avec Firefox 1.5 et 1.0.7
Je n'ai pas de version inférieure pour vérifier. Mais là, tu m'étonnes quand même. Des tas de sites proposent la solution du spacer avec une div vide, donc si ça ne passait pas avec Firefox / Mozilla, ils seraient moins enthousiastes, non ?
Bonsoir,
Oui j'ai trouvé ça étonnant aussi...

J'avais fait le test avec un Firefox 1.06. J'ai téléchargé après la version 1.07 : même résultat !

Je repasse tout à l'heure mettre une page de test en ligne similaire à celle que j'avais fait ce matin

A+
En fait ma page de test était la plus simple possible :
C'est par ici !

Le code source complet :
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<title>Test Clear</title>
<style type="text/css">
<!--
#parent {
	background-color: blue;
}
#parent img {
	float: left;
}
.spacer {
	clear: both;
}
-->
</style>
</head>
<body>
<div id="parent">
	<img src="test.gif" alt="image flottante" height="49" width="100" /> 
	test 
	<div class="spacer"></div>
</div>	
</body>

</html>

Résultat obtenu avec Firefox 1.501 win:
upload/4496-ff1501.png
Résultat avec Firefox 1.07 win :
upload/4496-ff107.png

A+
Modifié par Alan (15 Feb 2006 - 23:13)
Alan a écrit :
En fait ma page de test était la plus simple possible

J'avais aussi fait un test très très simple, mais j'avais oublié d'enlever un paramètre :

#conteneur {padding: 20px;}

Un simple padding en haut et en bas corrige le problème.
#conteneur {padding: 1px 0;}


Ça marche également avec les bordures
[code]#conteneur {
border-top: solid 1px transparent;
border-bottom: solid 1px transparent;
}/code]

Donc effectivement, il y a un problème. Mais celui-ci pose un véritable problème dans un seul cas : si on voulait utiliser un bloc conteneur uniquement pour placer une couleur ou une image de fond. Pour le reste...

Du coup je ne pense pas que je vais le signaler sur ma page de test. Le test que j'ai réalisé fonctionne correctement, mais effectivement dans un cas extrême et minimal ça n'est pas le cas. Mais s'il fallait développer chaque bug potentiel lié à un cas précis, il faudrait écrire un livre plutôt qu'un article.

Merci de l'info en tout cas !
Modifié par mpop (16 Feb 2006 - 00:07)
Effectivement, un padding bas ou une bordure bas empêche le problème. C'est un peu bizarre quand même Smiley ohwell
Merci en tout cas de m'avoir éclairé là dessus,

Bye