Il y a quelques temps, je m’étais interrogé sur les différentes manières de rétablir le flux après un float. A l’époque, mon vocabulaire en la matière était rustique mais solide : je contentais souvent d’un coup de clear: both appliqué soit à une balise div, hr ou br. Comme j’en ai appris un peu plus sur le clearing suite aux commentaires qui ont suivi, j’assure le service après-vente, ce qui fait de moi une espèce de Darty Monsieur Plus du CSS…
Pour « clearer » les « float », j’utilise désormais en première intention un overflow: hidden dont j’applique soigneusement la pommade sur le bloc qui contient les éléments flottants de manière à créer un contexte de formatage, le tout agrémenté d’une pincée de Ouidzzz !, de Zzoum ! ou de Héiiiitt… pour IE6 qui a besoin d’un petit câlin pour déclencher son fumeux fameux hasLayout sur lequel vous trouverez tout ce qu’il faut savoir chez blog-and-blues qui a mené de nombreux tests XHTML et CSS sur le sujet.
Voici quelques exemples de code que j’utilise pour rétablir le flux :
Avec overflow: hidden
.container-with-overflow { overflow: hidden; height: 1%; }
La propriété height: 1% peut être remplacée par zoom: 1; pour déclencher le hasLayout dans IE 6, à servir de préférence dans une feuille de style inclue à l’aide d’un commentaire conditionnel. A noter que IE7 « comprend » l’overflow (ce qui peut permettre de cibler uniquement IE6 dans ce cas-là). Notez que zoom: 1; est une propriété « propriétaire » de IE qui ne passe pas le validateur.
Avec la pseudo-classe :after
.container-with-generated-content { height: 1%; } .container-with-generated-content:after { content: "."; display: block; height: 0; clear: both; visibility: hidden; }
Vous avez remarqué que le height: 1% (ou zoom: 1) est toujours nécessaire pour déclencher le hasLayout chez IE 6 et IE 7 (et oui, ce dernier ne « comprend » pas la pseudo-classe :after…
Pourquoi présenter deux méthodes ? Simplement parce que si on utilise overflow: hidden pour déclencher le contexte de formatage, il ne pert pas pour autant sa fonction première : masquer le contenu qui dépasse d’un bloc. C’est souvent très pratique, par exemple lorsqu’on ne veut pas trop se soucier de la largeur des images, mais parfois très ennuyeux lorsque le bloc en question doit inclure un menu déroulant, car ce dernier risque d’être masqué lui aussi…
En faisant flotter le container lui aussi !
Une troisième méthode consiste à donner une largeur de 100% à l’élément container et à le faire flotter lui aussi :
.container-with-float { float: left; width: 100%; }
Est-ce la fin des anciennes méthodes ? C’est bien possible, même si dans la plupart des cas, le clear: both appliqué à une balise hr ou br peut se justifier, vu que généralement lorsqu’on a besoin de rétablir le flux, c’est qu’il y a une légère rupture sémantique qui peut être rendu par une ligne horizontale (peut-être moins un br, mais bon…). Disons que le test est simple : si en l’absence de CSS, les lignes hr ont l’air d’être posées comme un cheveu sur la soupe, c’est qu’il n’y en a pas besoin 😉
Pour en savoir plus sur les avantages et inconvénients de ces trois techniques, je vous invite à jeter un oeil chez Robert Nyman et chez Florent Verschelde pour tout savoir sur les marges et contexte de formatage.
Clearfix reloaded ! (màj du 23/02/2011)
Voici une nouvelle méthode pour le clearing permettant de mieux gérer la fusion des marges (cf. Clearfix Reloaded + overflow:hidden Demystified) :
.clearfix:before, .clearfix:after { content: "."; display: block; height: 0; overflow: hidden; } .clearfix:after { clear: both; } .clearfix { zoom: 1; }
Une variante utilisée dans HTML5 Boilerplate. Notez le remplacement de la propriété `overflow: hidden` par `visibility: hidden` :
.clearfix:before, .clearfix:after { content: "020"; display: block; height: 0; visibility: hidden; } .clearfix:after { clear: both; } .clearfix { zoom: 1; }
L’absence de la propriété `overflow: hidden` peut entrainer des problèmes d’espaces au-dessus de certains éléments. Pour y remédier, il est possible d’utiliser :
.clearfix2:before, .clearfix2:after { content: "020"; display: block; height: 0; overflow: hidden; } .clearfix2:after { clear: both; } .clearfix2 { zoom: 1; }
Quelques liens
- Très bonne analyse de Florent Verschelde en quatre parties sur les problèmes liés à l’utilisation des flottants. De nombreux exemples avec capture d’écran pour montrer les problèmes rencontrés sur les différents navigateurs :
- Clearer des floats sans élément superflu
- How to clear CSS floats without extra markup – different techniques explained — Le site sur lequel j’ai copié-collé les exemples pour illustrer cet article. Des explications concises et efficaces.
- Methods for Containing Floats — Contient des tableaux récapitulatifs des différentes méthodes de clearing et leur support par les navigateurs. Un must-read.
- How To Clear Floats Without Structural Markup
- Containing Floats
- IE/Win: relatively positioned parent and floated child – disappearance
- New clearing method needed for IE7?
Pour la route…
J’en profite pour vous annoncer que la première partie de ce billet est également disponible sur le portail developpez.com, dans la rubrique CSS o/
Developpez.com, c’est LE site de référence pour tout ce qui concerne les techniques de programmation. Je vous conseille tout particulièrement l’excellent outil XHTML développé par giminik (Matthieu Petiot) pour connaitre la hiérarchie des éléments et les imbrications autorisées par les spécifications.
On peut aussi mettre width:auto a la place de height:1% comme dans l’article que tu lies (sur le blog de rémi prevost) mais ça peut poser problèmes si on a un layout à largeur fixe dans ce cas height:1% devrait être mieux.
Y’a t il des différences entre zoom:1, height:1% et width:auto ?
@Vincent En fait j’ai toujours cru que toutes les valeurs de width autres que « auto » étaient bonnes.
Un width: 100% est bien mais mais n’est pas toujours la meilleure solution en fonction des contraintes liées au modèle de boite d’IE : il faut parfois ne pas mettre de width explicite lorsqu’on met du padding, par exemple.
Dans le cas qui nous intéressse (rétablir le flux) il n’y a pas de différence entre zoom: 1 et height: 1%, sauf que la propriété zoom ne fait pas partie des CSS, mais est spécifique à IE. Mais bon, vu qu’on utilise les commentaires conditionnels ça ne fait pas vraiment de différence 😉
Excellent article. Bravo et félicitations.
Je dois avouer qu’il m’arrive de m’arracher les cheveux avec ce genre de problèmes (je suis pas expert CSS^^) et c’est une solution qui parraît moins contraignante que d’apposer un br ou hr spacer juste après la boite flottante.
Thx
Hello,
Bon résumé. 🙂
Il faudra pour ma part que je mette à jour mes pages sur le dépassement des flottants, qui commencent à dater un peu.
Mieux vaut utilsier zoom, parce que ton height pourrait déplaire, ou un hack à la con comme _property:value; serait mieux, les comentaires conditionnels ce n’est pas génial (duplique tes feuilles de styles pour chaques navigateurs), et parler de valider du css en voulant faire des hack avec des comentaires conditionels, c’est de la branlette stylisé quand même (si j’puis me permettre).
À noter que le overflow:hidden; sert aussi — et surtout — à replacer un bloc suivant un élément en float — margin-left après un float:left; par exemple, cqfd — et ça, c’est priceless.
Excellent article, toujours aussi intéressant de te lire. Un grand merci
«les comentaires conditionnels ce n’est pas génial (duplique tes feuilles de styles pour chaques navigateurs)»
Romuald, je crois que tu devrais réviser l’utilisation des commentaires conditionnels. Car ce que tu viens de dire est une énormité. 😉
@Romuald >lapin tout compris ton commentaire, tu voulais dire quoi par « duplique tes feuilles de styles pour chaques navigateurs » ?
@Florent V. > +1 😉 (au fait, tu veux changer quoi, dans tes pages sur les flottants ?)
Je veux juste les reprendre pour présenter les faits du haut de ma plus grande expérience aujourd’hui (ces pages ont un peu plus de deux ans). Par exemple, je présente plusieurs solutions (trouvées à l’époque en faisant des recherches et des tests) mais sans conseiller de solution privilégiée ou de démarche particulière. L’exemple de départ avec son layout n’est pas idéal non plus. Enfin, je présente overflow:auto mais pas overflow:hidden, et ce dernier me semble être une meilleure solution (car overflow:auto peut faire apparaitre des barres de défilement inutiles en cas de légère imprécision de rendu du navigateur).
Bref, je ne sais pas encore à quoi ça ressemblera au final mais je compte me pencher dessus.
Pareil pour la page présentant une mise en page avec conteneur global en min-height:100%, il y a une solution simple à certains problèmes que je soulève, et je pense la remanier pour proposer cette solution «par défaut». Cent fois sur le métier remettre l’ouvrage. 🙂
@Florent V. C’est vrai que les choses évoluent, y compris notre propre pratique 😉 j’ai hâte de te lire à nouveau !
overflow:hidden c’est le mal !
En utilisant overflow:hidden vous allez empêcher les utilisateurs de votre site à modifier la taille de la police d’écriture, le fait de faire Ctrl + Molette impactera la police mais la coupera partiellement dans les blocs en hidden … pas très lisible n’est-ce pas ? 🙂
A partir de là, overflow:auto est devenu mon plus grand ami, il est vrai que des fois (sous Firefox surtout) ça « bug » du aux éléments doté d’un outline par exemple, il suffit de le prévoir dans son code en prévoyant 1 ou 2 pixel de padding sur l’élément en overflow:auto 🙂
@Yves Van Goethem > je n’ai jamais, mais alors jamais rencontré ce problème. Je l’utilise d’ailleurs sur ce blog (le container est en overflow: hidden et le texte est modifiable sans impacter la police 😉
Peux tu me fournir quelques éléments (navigateurs, fichier html et css, etc.) qui permettraient de vérifier ce comportement ? Si quelqu’un d’autre pouvait apporter des compléments d’informations, ce serait cool 😉
«overflow:hidden c’est le mal !»
Perdu. Mais il est préférable de bien l’utiliser. Bien entendu, si on fige la hauteur des conteneurs, mieux vaut utiliser un overflow:auto plutôt qu’un overflow:hidden, c’est pas tip top mais ça limite les dégâts. Mais si le conteneur a une hauteur fixe, on ne va pas s’amuser à empêcher le dépassement de flottants sans doute prévus pour tenir dans la hauteur prévue. Je suis perplexe, là…
Si le conteneur n’a pas de hauteur fixe (ou de hauteur maximale), l’utilisation de overflow:hidden ne pose problème que dans un seul cas: si un contenu (image ou chaine de caractères sans espaces) est plus large que le conteneur. Mais c’est assez ciblé comme problème. Donc pas de contrindication particulière pour ma part à l’utisation de overflow:hidden pour un conteneur extensible en hauteur.
Bon, ensuite si on fait des designs avec plein d’éléments avec une hauteur fixe en pixels (ou même en EM, soyons fous), c’est signe qu’il faut encore apprendre à designer pour le Web. 🙂
@Yves van Goethem,
@Florent V. >
Finalement j’ai réussi à reproduire un comportement emprunt de buggitude avec cette histoire d’overflow:hidden.
Sous IE6, si le bloc auquel on applique l’overflow: hidden n’a pas de largeur explicite (même en mettant height: 1%), le bloc disparait litéralement et réapparait avec overflow: auto.
C’est un peu différent de ce qu’évoquait Yves, mais peut-être qu’il y a matière à creuser.
« Mais il est préférable de bien l’utiliser »
@Florent : Oui voilà, je me suis mal exprimé, en réalité il s’agit plus de l’usage, j’ai été un peu trop catégorique en affirmant que c’est mal :p
Tiens j’ai oublié de préciser que le bug auquel je fais allusion au-dessus, apparait surtout si le bloc auquel on applique l’overflow: hidden n’a pas de largeur explicite ET est également en float: left…
Super intéressant cet article, merci pour tes méthodes que je ne connaissait pas…A utiliser! 🙂
Class… !
Je me disais bien que j’avais vu ça ici ^^
Ça vient de m’aider pour mon nouveau design, en ligne d’ici demain ou mercredi 😀
Merci.