Floats: I seek a deeper understanding

Here is an unordered list, with a red border
The list items have an orange border

See the list1.png attachment

<ul class=“test2” id=“list2”>
<li>Robin Hood</li>

#test {border: 1px solid #ff0000;}
#test li {border:1px solid orange; float left; }

The list elements are floated left, and taken out of the document flow. Therefore the UL shrinks to the size of 2px in height.

Is it possible to make the <ul> contain the floated list elements but…

Without making the list elements inline,
Without specifying the height of the <ul>

The list would appear like so
<– See the list2.png attachment

It’s mentioned in these articles:


Funny how there was a lot of antagonism over it at the time but is now the most commonly used containing mechanism :slight_smile: It’s not perfect and isn’t suitable for everything but like most things in CSS it has its good uses.

well, at least here, we all listen to you :slight_smile:

i have this “gift” though to get on people’s nerve by asking for a valid and complete understanding, instead of “i say so” explanations :lol: hope you won’t mind that in the future.

you need to put things in perspective and see how they connect to real science and knowledge.

Yes I’d agree with that. I like it when I get that “Eureka” moment and realise why something works the way it does.

to summarize:

the default behaviour of the box model: children element box models inside parent element box model.

box model for a parent element is calculated based on the box model of its children elements.

if all children element are floats, their box model has no significance in calculating dimensions for the parent element box; hence the box model for it has minimum dimensions, like for an empty element due to the default visible value in the overflow; but its still the loving parent we all know, the DOM says so :slight_smile:

all children elements floating and the overflow default value visible will cause an overflow for the parent element, naturally. any change in the overflow settings will cause changes in the box model. hence the default behaviour of the box model: children element box model inside parent element box model. qed :slight_smile:

nice one. you are a TRUE GURU, no doubt! and a gentleman, i can prove that also!

Thanks but I still have a lot to learn :slight_smile:

It’s discussions like these that make me review and check what I’m saying is true or not and I quite like it when someone finds a flaw because it shows that at least someone is listening :slight_smile:

I suppose I should clarify the exact reason that overflow (other than visible) makes an element contain its floated children and the answer isn’t specifically to do with overflow itself but the fact that overflow creates a block formatting context.

Elements that create new block formatting contexts are as follows:

These elements compute their height by this rule in the specs:

In addition, if the element has any floating descendants whose bottom margin edge is below the bottom, then the height is increased to include those edges. Only floats that are children of the element itself or of descendants in the normal flow are taken into account, e.g., floats inside absolutely positioned descendants or other floats are not.

That’s why floats contain child floats and display:inline-block contains floats and absolute elements contain floats etc. It is to do with the way that these elements compute their height because they establish new block formatting contexts.

nice one. you are a TRUE GURU, no doubt! and a gentleman, i can prove that also!

never read these articles before, but still no mention of the box model. this one gets me: pseudo-knowledge. this is why i trust that when someone gets lost in knowing a long list of fixes and hacks, that is usually nothing more than robot recording, but never manage to explain HOW in a credible manner, they fail completely as professionals.

if they were really seeking at the core knowledge, they would get past reciting some fixes like a monkey and proclaiming them self gurus :slight_smile:

the box model and the DOM are the base. you cannot overlook these and try to explain css features as “ufo sightings” and be proud of :lol:

you need to put things in perspective and see how they connect to real science and knowledge.

and the box model says it all about the behaviour of parent elements having only floats in it. and the box model IS THE KEY to css. but i don’t see many relating their techniques or explanations to it. and it gets me when they try pushing semi-fiction pass as knowledge.

Actually, no. The overflow and clearfix methods are enclosing floats, which is different from clearing them.

Anyone coming after an (unenclosed) float with “clear” on it will not ride up alongside the float (except in IE in special cases… because IE is a very special browser lawlz).
If the float’s parent encloses it (and not the following element), though, the next element in line isn’t clearing the float, but is simply not able to ride up because the float’s parent above has its bottom pushing the next element down. Though for good practice I’ll often still set “clear” on the following element anyway.
<h2/><–doesn’t need to clear anything, unless Div isn’t enclosing
If Div encloses Float, h2 has no worry.

<h2/><–needs clear
Here, h2 needs to clear the float, and it doesn’t matter to the h2 if Div encloses the float or not.

Setting overflow to anything other than the default, where the container now has to deal with “what if my children overflow?” will force the container to change behaviour (when Paul first found this PartTime job of overflow, some people thought it was a bug, but it makes sense with the specs). It cannot do anything about overflow if it cannot tell its children are overflowing, can it?

Another option, though with its own issues, is making the container display: table. Tables are required in The Law to always enclose their children. There is no “overflow” for tables really. It’s not allowed.

Floated containers of course see their own floats, but then someone might have to contain THAT box. I try to avoid Float Absolutely Everything because it gets sticky. Bleh.

By what witch craft would “overflow:hidden” make that work?

simple: box model. all elements have their place in the DOM and all elements have a box model.

your code:

<ul class=“test2” id=“list2”>
<li>Robin Hood</li>

is a html markup code that will generate a DOM for the elements. that DOM means <ul> will always account <li>s as its children. always. CSS float has no effect on the DOM.

now, if you don’t apply a css style of your own, the default style will generate boxes for all these elements. you may not see this boxes, but these have calculated dimensions. that means that <ul> will be the bigger box, with its dimensions calculated so that it will contain all the <li>s little boxes.

what happens when you float <li>s by using the css float left? than the <li>s are taken out of the normal flow, that is, the flow inside the <ul>, which has nothing to do with the overall document flow. how this taken out of the normal flow translates in presentation: the <ul> box model dimensions are now calculated w/o regards to the <li>s little boxes dimensions. that means, if <ul> has only floated elements, their boxes will not command the <ul> dimensions to grow over zero, the normal box model dimension for an empty element.

this disregard for the <li>s boxes dimensions in calculating <ul> box model gives us the next thing: overflow. obviously, if the parent has a box model that cannot contain its children boxes, we’ll have an overflow.

overflow has the default value visible. setting it to hidden will have the effect in recalculating the box model for the <ul>, which in return will make the <ul> VISUALLY containing its children again. but he was always aware that it was containing them. it just couldn’t cope with their box model dimensions, that’s all :slight_smile:

that is to say that <ul> was always aware its having children elements, because CSS float has no effect on the DOM. it just disregarded their box model when calculating its own, because that’s what float means.

Yes thank you I should have actually specified it better :).

A side note-overflow:scroll works too :wink:

a good addition: overflow:auto :slight_smile: thanks dresden_phoenix.

as per since when overflow attribute become a notorious solution: since web devs had a better look at the box model.

the knowledge is all there. all it takes is a little thinking :slight_smile:

Thanks for the help. I needed it. Your explanation was great.

You’re welcome :slight_smile:

It’s a special effect of the property. Any overflow value other hten visible will force a parent to recognize it has children and contain the floats :slight_smile:

Right now the parent thinks it has nothing in it and adding overflow makes the “blindfold” come off :wink:

By what witch craft would “overflow:hidden” make that work?

Add overflow:hidden; to #test to make it contain the children :slight_smile:

hm, looks like it must have been Roger’s page except I don’t remember the page in my head as being so… pink. But the comments by Anne and Phillipe are exactly what I remember.

nice one. you are a TRUE GURU, no doubt! and a gentleman, i can prove that also!

you sir, are a scholar and a gentleman. I adjust my monocle and tip my top hat in your direction

I should draw a poes with a top hat and a monocle.

Somewhere I found an old page… maybe a mailing list? It was people discussing the overflow: auto method and I remember Anne van Kesteren and some others wondering if it was a weird bug, and then someone else explaining what context a box needed to deal with overflow. I’ve never found that page since.

i was a teacher and i learned at least one thing from that: explaining to others makes you understand more.

i’ve joined SP for the same reason: when people here are explaining day in and day out they are bound to know more and better.

so far several people here, including you, proved my decision to be a very good one :slight_smile: and that’s all the behind kissing you’ll get from me today :lol: