Discussion :

[Hemgé]

Bonjour,

Débutant et donc en autoformation (assistée par vous, merci), j’aimerais obtenir une explication théorique à ce qui suit :

Lorsqu'on fait flotter les <LI> d'un <UL> qui reste dans le flux normal, cet <UL> perd en quelque sorte sa hauteur, comme l'illustre le code ci-dessous.

Pièce jointe 42343

Soit une liste non ordonnée (<UL> + <LI>), qu’on décore graphiquement pour mettre les comportements en évidence :
<UL> avec bordure et couleur de fond, avec une largeur à 100%
<LI> avec texte en couleur et couleur de fond

• En flux normal, sans appliquer aucune propriété influençant le positionnement, les <LI> se placent dans la boîte définie par <UL> et celui-ci développe la hauteur nécessaire pour accueillir les <LI>.

• Si on fait flotter les <LI> sans positionner le <UL> qui reste donc dans le flux normal, celui-ci voit sa hauteur réduite à zéro et le cadre se réduit à une ligne, les <LI> apparaissant sous cette ligne. Normal, me direz-vous, puisqu’un flottant sort du flux normal et que « les boîtes de bloc non positionnées, créée avant et après elle, s’écoulent verticalement comme si celle-ci n’existait pas. » (point 9.5 Les flottants) Même s’il sort du flux normal, le flottant reste quand même confiné à son bloc conteneur, à sa boîte parent, et il suffit de réduire la largeur du <UL> pour voir les <LI> se déplacer vers le bas, sans dépasser la ligne qui représente le cadre écrasé du <UL>.

• Mais, si on fait également flotter le <UL>, les <LI> se replacent dans la boîte développée par ce <UL>, qui retrouve ainsi une hauteur.

En plus de ce comportement dont je ne parviens pas à trouver l’explication dans les spécifications CSS du W3C, comme on a défini une largeur à 100% pour le <UL>, si les blocs flottants, soit le <UL> d’une part et les <LI> d’autre part, étaient tout à fait indépendants les <LI> devraient se trouver en-dessous du <UL>, puisque les flottants « vont buter sur le bord du bloc conteneur ou sur le bord externe d’un autre flottant.. » et « quand il n’y a pas assez de place pour le flottant dans la largeur de la ligne, celui-ci se déplace vers le bas ».

Les <UL> et <LI> restent donc bien en interdépendance (ouf !), mais comment expliquer l’écrasement du <UL> lorsqu’on fait flotter les <LI> et la récupération de sa hauteur par le <UL> lorsqu’on le fait également flotter.
Qu'ai-je raté dans les références ?

Avec mes remerciements au « corps professoral »

[Macmillenium]

Bonjour,

Je vois que tu as bien compris la notion d'un élément positionné et son impact sur le flux normal, c'est un comportement standard.

Ne te prend pas trop la tête, si tu veux qu'un bloc englobe ses enfants flottants, il faut établir ce qu'on appelle un contexte de formatage bloc via la propriété overflow sauf avec la valeur visible

[Hemgé]

Merci, MacMillenium.

Mais pour l'instant, je ne rencontre pas de problème pratique à ce niveau.

Mon souci est de trouver la "théorie" sous-jacente à ce comportement.
Ai-je manqué quelque chose dans les spécifications, ? Les ai-je mal interprétées ?

Ceci, pour m'assurer une meilleure qualité de développement et de traçage d'éventuels problèmes, plutôt que de démarrer plus vite mais sur des bases incertaines.

Donc, la question reste posée.
Si quelqu'un a une suggestion ou LA réponse, ...

[Macmillenium]

Mais, si on fait également flotter le <UL>, les <LI> se replacent dans la boîte développée par ce <UL>, qui retrouve ainsi une hauteur.

C'est normal, la propriété float confère également un nouveau contexte de formatage bloc mais attention car le même problème se posera au niveau du conteneur de <ul>

Qu'ai-je raté dans les références ?

Oui je pense

Ceci, pour m'assurer une meilleure qualité de développement et de traçage d'éventuels problèmes, plutôt que de démarrer plus vite mais sur des bases incertaines.

Exactement

[Hemgé]

Sorry Macmillenium,

Mais votre réponse ne m'avance pas.

Je ne cherche pas une solution, mais la "règle", ou plutôt la (petite ?) nuance que j'ai ou aurais manquée ou incomplètement interprétée dans le point 9.5 des spécifications W3C.

Et,

Oui je pense[/QUOTE]

me renvoyer globalement au point "9.5 Les flottants " des spécifications, sans m'indiquer une ligne précise ne m'aide pas.


D'autre part,

C'est normal, la propriété float confère également un nouveau contexte de formatage bloc mais attention car le même problème se posera au niveau du conteneur de <ul>

je ne pense pas que la notion de nouveau contexte de formatage explique le comportement relevé.

Que du contraire :
Que <UL> crée un nouveau contexte de formatage par rapport à son conteneur concerne la relation avec l'amont, nous sommes d'accord.
Mais justement, ici, alors que <LI> crée un nouveau contexte de formatage par rapport à son <UL>, faire flotter le <UL> replace le <LI> dans cet <UL>, annulant en quelque sorte le nouveau contexte de formatage créé par le float du <LI>.

Mais, merci quand même.

Je continue à chercher mais pas en haute priorité et si je trouve la réponse, je remonterai le sujet.

Bonne semaine.

[Macmillenium]

Salut Hemgé,

me renvoyer globalement au point "9.5 Les flottants " des spécifications, sans m'indiquer une ligne précise ne m'aide pas.

Pourrais tu nous dire qu'est ce qu'il manque comme explication ?

Que <UL> crée un nouveau contexte de formatage par rapport à son conteneur concerne la relation avec l'amont, nous sommes d'accord.
Mais justement, ici, alors que <LI> crée un nouveau contexte de formatage par rapport à son <UL>, faire flotter le <UL> replace le <LI> dans cet <UL>, annulant en quelque sorte le nouveau contexte de formatage créé par le float du <LI>.

Il n y a rien d'annuler, là il s'agit d'un rapport entre la balise <ul> et ses enfants <li>.
- Comme tu l'as remarqué, faire flotter les <li> les retirent du flux normal par rapport a leurs conteneur parent <ul>.

- Faire flotter l'ul établi un nouveau contexte de formatage
|-> ul englobe alors ces enfants flottants.
|-> ul est aussi retiré du flux normal par rapport a son conteneur parent et ainsi de suite.

Finalement tu va te retrouver obliger de flotter tous tes blocs conteneurs.

[Erwan31]

Bonjour,
tout d'abords mieux vaut se référer à la spec CSS2.1 (uniquement en anglais) qui diffère de la spec CSS2 sur un certain nombre de points.
http://www.w3.org/TR/CSS21/visuren.h...ock-formatting

Les blocs en position absolue, flottant (float), les éléments de rendu table-cell (pour ne citer qu'eux) et en overflow (autre que que la valeur initiale visible) s'adaptent à leur contenu, et je dirais simplement que c'est comme ça.

Si tu veux savoir pourquoi, faut poser la question à un membre du CSS Working Group comme le fameux Daniel Glazman (le seul français du group à ma connaissance), mais pourquoi veux tu savoir ça? Simple curiosité?

D'autre part ne pas oublier de préciser Macmillénium que l'établissement du contexte de formatage block dans IE6- par l'overflow:hidden nécessite
de conférer le layout au bloc (via un zoom:1 par exemple dans une css ie appelée avec les commentaires conditionnels qui vont bien) pour qu'il englobe ses enfants flottants.

[Macmillenium]

Salut Erwan31,

D'autre part ne pas oublier de préciser Macmillénium que l'établissement du contexte de formatage block dans IE6- par l'overflow:hidden nécessite
de conférer le layout au bloc (via un zoom:1 par exemple dans une css ie appelée avec les commentaires conditionnels qui vont bien).

A mes connaissances, IE7- n'établit pas de contexte de formatage bloc, donc le overflow:hidden n'a aucune influence dans le cas de float.
Conférer un layout suffit largement pour corriger ce problème.

[Erwan31]

Salut Erwan31,
A mes connaissances, IE7- n'établit pas de contexte de formatage bloc, donc le overflow:hidden n'a aucune influence dans le cas de float.
Conférer un layout suffit largement pour corriger ce problème.

Oui je sais bien un zoom:1 seul permet au conteneur d'englober ses enfants flottant même sur IE7 mais un overflow:hidden seul suffit aussi, donc a priori il y a établissement du contexte de formatage sur cette version.

@Hemgé Pour ton info et puisque tu es curieux le concept de haslayout a disparu dans IE8 dont le layout engine a été refondu entièrement.

[Hemgé]

Re-bonjour à tous !

Suite à la suggestion d'Erwan31, j'ai été lire la doc CSS2.1 et j'y ai trouvé "LA" réponse.

Pour résumer pour ceux qui prennent le sujet en marche, mon problème était le suivant :

- si je fais flotter des <LI> au sein d'un <UL> situé lui dans le flux normal, les <LI> sortent du flux du <UL>, ce qui se traduit par un "collapsing" du <UL>, ce que j'appelais perte de hauteur UL dans mon titre ;

- si je fais flotter des <LI> au sein d'un <UL> lui-même flottant, les <LI> ne sortent pas du flux du <UL>, or ces <LI> flottants devraient sortir du contexte de formatage <UL> en cours et c'est là que les réponses reçues ne me satisfaisaient pas :

• ni la notion de nouveau contexte ;

• ni la notion que le UL englobait ses enfants flottants, puisque le float des LI enfants est déclaré après le float du UL ;

• ni la notion que certains blocs s'adaptent à leur contenu et que c'est "comme ça", puisque justement c'est pourquoi c'est "comme ça" que je cherchais à éclaircir pour disposer d'un point de référence théorique.

In fine, je trouve la petite phrase qui sauve dans les dernières spécifications (en anglais) http://www.w3.org/TR/CSS21/visuren.h...-next-to-float, à savoir, au 9.5 Float :

(j'ai repris deux paragraphes juste pour faciliter le repérage du second paragraphe qui seul nous intéresse)

As stated in section 8.3.1, the margins of floating boxes never collapse with margins of adjacent boxes. Thus, in the previous example, vertical margins do not collapse between the P box and the floated IMG box.

The contents of floats are stacked as if floats generated new stacking contexts, except that any elements that actually create new stacking contexts take part in the float's parent's stacking context. (...)

Pour le reste (IE et ses particularités), je n'y suis pas encore, mais j'en tiendrai compte évidemment.

Tout grand merci, Macmillenium et Erwan31.

Je ne clos pas le sujet tout de suite, au cas où quelqu'un aurait un commentaire.