dorayme <doraymeRidThis@optusnet.com.au> wrote in news:doraymeRidThis-
10CA04.15233508042008@news-vip.optusnet.com.au:

> In article <WoOdnYR9Y7aBZWfanZ2dnUVZ_gKdnZ2d@golden.net>,
> Gus Richter <gusrichter@netscape.net> wrote:
>
>> dorayme wrote:
>> >
>> > I am inclined to actually use the phrase "containing block" where the
>> > context shows it to do a job of containing.
>> >
>
> In the float rules you refer to, the idea of containment, as I have been
> thinking about it, refers to a parent in a particular set up

The containing block is not neccessarily the parent.


--
Richard
Killing all threads involving google groups
The Usenet Improvement Project: http://improve-usenet.org

On 2008-04-04, Gus Richter <gusrichter@netscape.net> wrote:
> dorayme wrote:
>
>> This is not right Gus. The float does it all by itself for its own text.
>> The div (as you have them) are not doing *this* shrink-wrapping thing
>
> Fine. The text wraps around the float. Forget about the word
> "Shrinkwrapping". No problem.
>
> Perhaps you confuse the float somehow. The float is a box with "Some
> text and more" with a green background. You say I should remove the
> dimensions. I have no idea why when I desire them. Remember that the
> float could be an image with its dimensions. I also wish to set the
> width for shrink box just because I can and to see it wrap around the float.
>
>> Remove the widths on everything completely (which are not needed for
>> your interesting question btw) to see.
>
> No! The dimensions are needed! As is! In my examples!
>
> 1. In the 1st example it shows text wrapping around a float.
> 2. In the 2nd example position:relative; is applied to #shrink.
> #float now goes behind #shrink. _Why?_

Because it's positioned, and therefore in stacking level 6 rather than
in stacking level 3.

The float is always in stacking level 4. 3 is behind 4, 6 is on top of
it.

These levels are described in CSS 2.1 9.9.1.

Note that "positioned" includes position: relative (see definition in
9.2.3).

All that stuff in Appendix E and elsewhere about how some boxes appear
to start stacking contexts to any of their descendents that don't
themselves start them but not to to those that do is just a funny
(though precise) way of saying that when a box is restacked it brings
most of its descendents with it.

It wouldn't be much good if in markup like this:

<div style="float: left">
<div>hello</div>
</div>

the outer div was brought in front of other things but the inner one got
left behind where it was.

[...]

If you mean "_Why_?" in the sense of why does the spec say this, my
guess is that it's because position: relative boxes are containing
blocks for absolutely positioned descendents: it therefore makes sense
for them to be stacked in the same sort of position on the z-axis as
them.

Another guess at why is that when you position something and actually
offset it with top/left etc. it just moves and nothing gets out of its
way or flows around it in its new position. It's usually more obvious
what's going on if it obscures other things on the page rather than
hiding behind them. Hence the higher stacking level for all positioned
boxes including relative.

On 2008-04-04, Jeff <jeff@spam_me_not.com> wrote:
> dorayme wrote:
>> In article <MPWdnYQR98QBFWjanZ2dnUVZ_sednZ2d@golden.net>,
>> Gus Richter <gusrichter@netscape.net> wrote:
>>
>>> #shrink {border: 1px solid;background: #ffc;width:8em;}
>>
>> OK Gus, will take a look. But I am puzzled why you talk of #shrink being
>> "shrinkwrapped"
>
> Oh, there is some web design book that calls it that. I had never heard
> of it until then.
>
> Something about floats shrinking to the minimum size of the contents,
> again something I'm unfamiliar with.
>
> Perhaps someone can elaborate on this.

Yes, it's called "shrink-to-fit" and describes the width you get when
you set width to auto on certain elements (tables, table cells, floats,
absolutely or fixed positioned boxes).

It is a technical term and is in the CSS spec.

But I don't think that's what Gus meant by "shrinkwrap". I think he just
meant "contains inline content that happens to flow around floats".

On 2008-04-04, dorayme <doraymeRidThis@optusnet.com.au> wrote:
[...]
> Giving an element a position, even a relative one, seems to take it "out
> of the flow" in a notional sense (even if there are no offsets
> specified).

Technically it is still "in the flow" (this is the way the spec talks
about it). But stacked differently, and offset if you offset it of
course.

Actually much of the usefulness of position: relative seems to be that
you get normal flow for the 2D position but become a container for
positioned descendents and can set z-index.

The fact that a relatively positioned box gets the same stacking level
as absolutely positioned boxes is perhaps a bit surprising but
reasonable given that it is the container for them.

Here is an example:

<div style="float: left; height: 300px;
width: 100px; background-color: green">
</div>
<div style="position: relative; background-color: blue; height: 100px;">
<div style="position: absolute;
top: 10px; left: 10px; background-color: red;">
foo
</div>
</div>

It's probably more intuitive that the blue div should be on top of the
green one rather than behind it since it is the containing block for the
red one.

Otherwise the red one would be on top of the green one but positioned
relative to something behind the green one that you can't see which
would be a bit weird.

It is on top as a consequence of the rule that relatively positioned
boxes are in stacking level 6 not 3. So hence the rule perhaps.

Ben C wrote:
>
> Because it's positioned, and therefore in stacking level 6 rather than
> in stacking level 3.
>
> The float is always in stacking level 4. 3 is behind 4, 6 is on top of
> it.
>
> These levels are described in CSS 2.1 9.9.1.
>
Yes thank you. In the first post I mentioned the stacking order, but
never looked to see what the spec had to say. My bad. Dorayme jogged my
memory by mentioning Appendix E and then it fell into place.

I had given a quick stacking order. I note that you have given a
different one. I still have to read through them in detail.

When time permits I try some of the many variables possible. Dorayme
seems to be doing likewise.

--
Gus

Gus Richter wrote:
>
> When time permits I try some of the many variables possible. Dorayme
> seems to be doing likewise.
>
I note that on alt.html dorayme is responding to a question "DIV -
dynamic height" wherein she gives another variable on her referenced page:
<http://netweaver.com.au/floatHouse/page10.html>
That page should be included in this thread as well.
The terminology of nuclear family should be removed, however, and
replaced with "containg block" and "floats". IMHO of course.

--
Gus

On 2008-04-05, Gus Richter <gusrichter@netscape.net> wrote:
> dorayme wrote:
>>
>> There is a fairly fairly consistent rendering of the phenomenon you have
>> been wondering about, this is true. So some rules are being followed! I
>> find the the talk of the various contexts, stacking etc not easy to
>> negotiate - to be frank.
>
> The thing about stacking order for layers is that normally we say that
> elements must be positioned to overlap in order for any z-index to
> visually take effect.

Things can overlap quite easily without being positioned, especially
when overflow and overflow: visible are involved.

[...]
> Well, in the instance of a float we actually already have the float
> layered on top of the containing block with line boxes (which we've been
> calling div#shrink in our examples) and regarding this the spec
><http://www.w3.org/TR/CSS21/visuren.html#floats> has this to say:
>
> "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.
> A float can overlap other boxes in the normal flow (e.g., when a
> normal flow box next to a float has negative margins). When this
> happens, floats are rendered in front of non-positioned in-flow
> blocks, but behind in-flow inlines."

The common case of a float on top a box it would be underneath
(if it didn't get a higher stacking level) is this kind of thing:

<p>
blah blah
<span style="float: left; height: 500px; width: 200px"></span>
blah blah
</p>
<p>
blah blah blah
</p>

The float sticks out of the bottom of the first P, but is stacked on
top of the second P, even though the second P comes later in the
document. Assume P has a non-transparent background in this example.

I think that's the basic reason for giving floats a higher level than
normal flow blocks.

The inlines go on top of the float but usually they don't need to
because they flow around it.

On 2008-04-06, Gus Richter <gusrichter@netscape.net> wrote:
> dorayme wrote:
>>
>> I earlier gave an indication of a test for when it has sunk in for a
>> normal human. It was a predictive one, not a hindsight one. I am still
>> not as optimistic as you.
>>
>> The slight thing that worries me in my pessimism is that many browsers
>> *do* the same thing, so someone or some group who programmed the
>> browsers had a certain understanding of these things. However, I can't
>> even be sure of this. It may turn out that the programmers put in a set
>> of rules and one of the consequences is the phenomenon you raised, but
>> it takes a blind machine to bring it out (like a not particularly
>> intended consequence).
>>
>> What would be nice is a model that tells a story that is consistent and
>> meaningful and useful. That one can see in practical circumstances as
>> useful. That one can understand for prediction. I am suspicious of the
>> act of staring at tracts of convoluted human unfriendly systems of rules
>> and saying in hindsight, ah, the penny has dropped. This seems to me to
>> be a different kind of understanding than the one that can predict
>> things.
>
> We can predict consistent behaviour as soon as we accept that:
>
> 1. The float's real estate covers that of the containing block, where
> both start at 0,0 (without any positioning). Either may have smaller or
> larger width and/or height.
> 2. In the instance of a float we actually 'already' have the float
> layered on top of the containing block with a pre-established stacking
> order.
> 3. _Without any positioning applied_ to the containing block, the float
> has a higher stacking order. The float is on top.
> 4. _With positioning applied_ to the containing block, the containing
> block has a higher stacking order. The float is on bottom.
> 5. _With positioning applied_, the stacking order may be changed by
> applying z-index to the containing block.

Exactly right.

Not sure if it answers dorayme's question, but for that you have to ask
what are the reasons for wanting to bring floats and positioned boxes
forward in the stacking order, and what would happen if you didn't.

The idea of the rules is for the default behaviour to give you what you
want most of the time. You can always z-index if you need to do unusual
things.

On 2008-04-07, Gus Richter <gusrichter@netscape.net> wrote:
[...]
> In my examples, "wrapper" and "containing block" are two different things.
> The "wrapper" is simply used to reposition the segment pairs. In your
> examples in the link I mention above, you use headings to accomplish
> this w/o wrappers.
> The "containing block" is each one of the yellow boxes in every one of
> your examples on the page linked above (yellow boxes in my examples as
> well). It is a bit counter-intuitive in that normally a container comes
> first in the markup, but in the case with floats, the "container block"
> comes _after_ the float.

No the containing block for a float is always above it in the document
tree.

But floats "invade" subsequent blocks in the same block formatting
context. So if you do this:

body
float
div

the text in the div flows around the float. But the float's containing
block is still body.

This kind of situation is further complicated by the fact that the div's
top margin collapses with that of body regardless of the float.

body
div
float

therefore often looks the same, although here the float's containing
block is the div, not body.

On 2008-04-08, Gus Richter <gusrichter@netscape.net> wrote:
> dorayme wrote:
>>
>> I am inclined to actually use the phrase "containing block" where the
>> context shows it to do a job of containing.
>>
>> Because the point is that it is the container, the parent, the big house
>> where the children live... It is crucial that it is on the container,
>> the parent, that rel pos is made for the abs to work.
>>
>> And I find it interesting how the "layers" work and yet the float still
>> exerts the influence to push aside (displace) the text or pics in the
>> following divs. Just had never thought of the float rules operating from
>> a smothered "underneath" position! Those float rules are powerful voodoo
>> huh? <g>
>
> 1. Any floated item will be out of the normal flow.
> 2. When floated left, it will position itself to top,left (0,0) of its
> "container block".
> 3. The special feature of a float is that any inline box content in the
> "container box" will shift over to make room for the float.
> 4. Blah, blah, blah, blah.
>
> You are having difficulty in accepting the container thing, so try
> asking yourself:
> "If the float positions itself to 0,0 of the container block,
> then what could be the container block?"

Sometimes 0,0 of more than one container blocks occupy the same pixel on
the screen, so this is not a good criterion.

body
float
div

In this example, 0,0 of div and body are in the same place because of
margin collapsing.

So which is the containing block for the float? Body, not the div,
because it's the block level ancestor as specified.

On 2008-04-09, Gus Richter <gusrichter@netscape.net> wrote:
> Ben C wrote:
>>
>> Because it's positioned, and therefore in stacking level 6 rather than
>> in stacking level 3.
>>
>> The float is always in stacking level 4. 3 is behind 4, 6 is on top of
>> it.
>>
>> These levels are described in CSS 2.1 9.9.1.
>>
> Yes thank you. In the first post I mentioned the stacking order, but
> never looked to see what the spec had to say.

I may have got them wrong. The point is though that it comes forward
because it's positioned and positioned beats floated.

> My bad. Dorayme jogged my
> memory by mentioning Appendix E and then it fell into place.
>
> I had given a quick stacking order. I note that you have given a
> different one. I still have to read through them in detail.

Even I have never read all of Appendix E. The section under z-index
(9.9.1) is more manageable.

Ben C wrote:
> On 2008-04-05, Gus Richter <gusrichter@netscape.net> wrote:
>> dorayme wrote:
>>> There is a fairly fairly consistent rendering of the phenomenon you have
>>> been wondering about, this is true. So some rules are being followed! I
>>> find the the talk of the various contexts, stacking etc not easy to
>>> negotiate - to be frank.
>> The thing about stacking order for layers is that normally we say that
>> elements must be positioned to overlap in order for any z-index to
>> visually take effect.
>
> Things can overlap quite easily without being positioned, especially
> when overflow and overflow: visible are involved.

I will have to check at a later date about z-index and overflow ...

I was simply saying that "normally" we say ..... Well, here ...

> [...]
>> Well, in the instance of a float we actually already have the float
>> layered on top of the containing block with line boxes (which we've been
>> calling div#shrink in our examples) and regarding this the spec
>> <http://www.w3.org/TR/CSS21/visuren.html#floats> has this to say:
>>
>> "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.
>> A float can overlap other boxes in the normal flow (e.g., when a
>> normal flow box next to a float has negative margins). When this
>> happens, floats are rendered in front of non-positioned in-flow
>> blocks, but behind in-flow inlines."
>
> The common case of a float on top a box it would be underneath
> (if it didn't get a higher stacking level) is this kind of thing:
>
> <p>
> blah blah
> <span style="float: left; height: 500px; width: 200px"></span>
> blah blah
> </p>
> <p>
> blah blah blah
> </p>
>
> The float sticks out of the bottom of the first P, but is stacked on
> top of the second P, even though the second P comes later in the
> document. Assume P has a non-transparent background in this example.

Even with a background color applied to the float in order to see it,
there is no stacking at all. Am I missing something?

> I think that's the basic reason for giving floats a higher level than
> normal flow blocks.
>
> The inlines go on top of the float but usually they don't need to
> because they flow around it.

Ben C wrote:
> On 2008-04-06, Gus Richter <gusrichter@netscape.net> wrote:
>> dorayme wrote:
>>> I earlier gave an indication of a test for when it has sunk in for a
>>> normal human. It was a predictive one, not a hindsight one. I am still
>>> not as optimistic as you.
>>>
>>> The slight thing that worries me in my pessimism is that many browsers
>>> *do* the same thing, so someone or some group who programmed the
>>> browsers had a certain understanding of these things. However, I can't
>>> even be sure of this. It may turn out that the programmers put in a set
>>> of rules and one of the consequences is the phenomenon you raised, but
>>> it takes a blind machine to bring it out (like a not particularly
>>> intended consequence).
>>>
>>> What would be nice is a model that tells a story that is consistent and
>>> meaningful and useful. That one can see in practical circumstances as
>>> useful. That one can understand for prediction. I am suspicious of the
>>> act of staring at tracts of convoluted human unfriendly systems of rules
>>> and saying in hindsight, ah, the penny has dropped. This seems to me to
>>> be a different kind of understanding than the one that can predict
>>> things.
>> We can predict consistent behaviour as soon as we accept that:
>>
>> 1. The float's real estate covers that of the containing block, where
>> both start at 0,0 (without any positioning). Either may have smaller or
>> larger width and/or height.
>> 2. In the instance of a float we actually 'already' have the float
>> layered on top of the containing block with a pre-established stacking
>> order.
>> 3. _Without any positioning applied_ to the containing block, the float
>> has a higher stacking order. The float is on top.
>> 4. _With positioning applied_ to the containing block, the containing
>> block has a higher stacking order. The float is on bottom.
>> 5. _With positioning applied_, the stacking order may be changed by
>> applying z-index to the containing block.
>
> Exactly right.
>
> Not sure if it answers dorayme's question, but for that you have to ask
> what are the reasons for wanting to bring floats and positioned boxes
> forward in the stacking order, and what would happen if you didn't.
>
> The idea of the rules is for the default behaviour to give you what you
> want most of the time. You can always z-index if you need to do unusual
> things.

My view/read exactly.

--
Gus

On 2008-04-09, Gus Richter <gusrichter@netscape.net> wrote:
> Ben C wrote:
[...]
>> The common case of a float on top a box it would be underneath
>> (if it didn't get a higher stacking level) is this kind of thing:
>>
>> <p>
>> blah blah
>> <span style="float: left; height: 500px; width: 200px"></span>
>> blah blah
>> </p>
>> <p>
>> blah blah blah
>> </p>
>>
>> The float sticks out of the bottom of the first P, but is stacked on
>> top of the second P, even though the second P comes later in the
>> document. Assume P has a non-transparent background in this example.
>
> Even with a background color applied to the float in order to see it,

Yes you do need a non-transparent background on the float.

> there is no stacking at all. Am I missing something?

Perhaps it will to give the <p>s also thick borders. The point is
just that the float is stacked on top of the second P's background
instead of going behind it.

That's because floats get a higher stacking level. Consider this
alternative, with no floats:

div.p
{
background-color: red;
height: 40px;
margin: 10px;
border: 10px solid gray;
}
div.notfloat
{
background-color: green;
width: 100px;
height: 300px;
/* float: left */
}

<div class="p">
blah blah
<div class="notfloat">
not a float
</div>
</div>
<div class="p">
blah blah blah
</div>

And then uncomment float: left to see the difference.

On 2008-04-10, dorayme <doraymeRidThis@optusnet.com.au> wrote:
> In article <slrnfvordn.6kn.spamspam@bowser.marioworld>,
> Ben C <spamspam@spam.eggs> wrote:
>> On 2008-04-06, Gus Richter <gusrichter@netscape.net> wrote:
[...]
>> > We can predict consistent behaviour as soon as we accept that:
>> >
>> > 1. The float's real estate covers that of the containing block, where
>> > both start at 0,0 (without any positioning). Either may have smaller or
>> > larger width and/or height.
>> > 2. In the instance of a float we actually 'already' have the float
>> > layered on top of the containing block with a pre-established stacking
>> > order.
>> > 3. _Without any positioning applied_ to the containing block, the float
>> > has a higher stacking order. The float is on top.
>> > 4. _With positioning applied_ to the containing block, the containing
>> > block has a higher stacking order. The float is on bottom.
>> > 5. _With positioning applied_, the stacking order may be changed by
>> > applying z-index to the containing block.
>>
>> Exactly right.
>
>
> Thanks for all the explanations in this thread. I found all of them
> ful for various reasons.
>
> On the question of predictability, to be perfectly frank, I don't *know*
> this is *exactly* right because I don't know who - really - are the "we"
> that Gus refers to. Or what - really - "predict" means here. Or even
> quite what is to be explained (there have been a few variations on a
> theme in this thread).
>
> If browsers can go different ways on some combinations, so too might
> humans. And we don't actually know if it is all consistent.
>
> It is a difficult issue and who will have the patience to look at it! I
> have this idea that the css specs set can be seen to talk to browsers
> and/or to talk to the human mind. In order to talk to browsers it has to
> initially talk to humans who program the browsers. We know for a fact
> that humans program browsers a bit differently and so this is some
> evidence that they read the same bible words differently (not complete
> evidence, they may perhaps all read it the same way but are differently
> beholden to pressures, commercial and other and ignore what they read).

Sometimes the programmers don't understand the spec, sometimes they just
get it wrong (bugs), sometimes they have something that's almost right
and mostly works (and may pre-date the spec) and that's a lot of risk to
change.

Occasionally they ignore the spec deliberately where it just seems
wrong-headed, but this is rare these days with CSS.

> Once instantiated in real code, we get machine predicticability.

Up to a point but some bugs can be very unpredictable!

> Given the same set of circumstances, they do the same thing.

Yes, although sometimes the circumstances can depend on timing, the
contents of uninitialized memory (i.e. whatever was left there by the
last program that used that bit of memory), and things well outside the
scope of what you thought was the input you were giving the program.

> Machines have little worries or doubts about the meaning of their
> instructions. If they don't understand them, they just ignore them.

They often crash too.

> And if they seem to understand them, they ipso facto do understand
> them and simply act on their understanding. And we can learn the ways
> of this machine up to a point.

Up to a point, but it's very hard to debug a program without the source
code, although this is effectively what some web developers have had to
do to improve predictability with IE.

The best advice for any web developer targetting crappy browsers is to
try to stick to the subset of the specification that does work. If you
find something that doesn't work as you expect check whether it's
actually wrong according to the spec. If it is, don't try to
second-guess it, reverse-engineer it, or touch it with a bargepole but
find some other way of doing it.

If it is wrong according to the spec it's more likely to be different in
different browsers and also in newer releases of the same browser.

> I have previously made the point in this thread that there is a lot of
> agreement among browsers on a lot of things to do with visual order
> and this speaks of an underlying logic.
>
> But there is another interesting issue to do with human mental
> ergonomics. The fit of html and css to the human mind is not exactly
> one of the wonders of the world. Not like English which ranks up there
> with the Sydney Opera House as an eighth wonder.

> If you hand picked a few people and asked them to draw what they would
> expect to see from various snippets of code, you would get a fair bit of
> agreement on a lot of things. But what things and what are the
> conditions for this imaginary experiment? Who is to be picked? Have we
> picked the wrong people if they go all wobbly or differ among
> themselves?

The problem is that what seems intuitively right in one situation is not
always what you want in another.

Take floats for example: when people use them for columns they are
surprised that the container doesn't make any height for them.

But if someone were using them to embed figures in paragraphs of text,
they would be equally surprised and annoyed if each container stretched
to fit the floats leaving big gaps between the text in each paragraph.

How to avoid annoying surprises is one of the difficult things about
designing any kind of human/machine interface.

Broadly there are two schools of thought here. Do you make a simple but
powerful system for which people have to read the manual and write
correct input (but it's for their own good), or do you give them lots of
features to do every little thing and accept any input with hidden rules
for "doing what they mean"?

Compare your old camera which had one dial for shutter speed and one for
aperture with your new one which replaced them with a button for
mountains, another one for people in front of mountains, one for the sun
rising over the same mountains, one for pictures of galloping horses,
people wearing large hats, tulips, skyscrapers, the moon, etc.

HTML/CSS seems to ended up with a bit of both design policies, to the
point where some authors are using obscure side-effects of overflow:
hidden because they understand what the machine is supposed to do and
others are setting vertical-align: middle on DIVs because they want them
vertically aligned to the middle of something.

> Thought experiments are one thing and real field tests are another
> altogether. It is well known that the world has a bad habit of biting
> the most scientific thoughts and predictions.
>
> It is easy to say stuff in hindsight. Well, let me qualify that! It is
> *not* always so easy! Some people do it brilliantly. Ben C does it
> better than anyone (at least to my ears).

Thank you

> I am not belittling the hindsight test as much as the use of the word
> "hindsight" suggests. But a hindsight test is *not* a prediction test.
>
> And, crucially, the word "prediction" is not some piece of linguistic
> magic that imprints its meaning on all mortal beings in the same way. I
> say this because there will be a lot of people who think they know
> *exactly* what is meant by *the rules predict the behaviour* and I am
> just a little bit more skeptical.
>
> I am not trying to be awkward. I *am* this without effort most of the
> time <g>

It is good to try to have an intuitive understanding of why the rules
are the way they are. There is some kind of rationale for most of it and
if you can figure it out there's much more chance you can implement it
correctly as a programmer or find the simplest ways to get the rendering
effects you want as an author/designer.

Ben C wrote:
> On 2008-04-08, Gus Richter <gusrichter@netscape.net> wrote:
>> dorayme wrote:
>>> I am inclined to actually use the phrase "containing block" where the
>>> context shows it to do a job of containing.
>>>
>>> Because the point is that it is the container, the parent, the big house
>>> where the children live... It is crucial that it is on the container,
>>> the parent, that rel pos is made for the abs to work.
>>>
>>> And I find it interesting how the "layers" work and yet the float still
>>> exerts the influence to push aside (displace) the text or pics in the
>>> following divs. Just had never thought of the float rules operating from
>>> a smothered "underneath" position! Those float rules are powerful voodoo
>>> huh? <g>
>> 1. Any floated item will be out of the normal flow.
>> 2. When floated left, it will position itself to top,left (0,0) of its
>> "container block".
>> 3. The special feature of a float is that any inline box content in the
>> "container box" will shift over to make room for the float.
>> 4. Blah, blah, blah, blah.
>>
>> You are having difficulty in accepting the container thing, so try
>> asking yourself:
>> "If the float positions itself to 0,0 of the container block,
>> then what could be the container block?"
>
> Sometimes 0,0 of more than one container blocks occupy the same pixel on
> the screen, so this is not a good criterion.
>
> body
> float
> div
>
> In this example, 0,0 of div and body are in the same place because of
> margin collapsing.
>
> So which is the containing block for the float? Body, not the div,
> because it's the block level ancestor as specified.

I agree.
My explanation of 0,0 of the container block fits simplistically.
The following condenses the spec a little more in detail:

1. Any floated item will be out of the normal flow.
2. A float will position itself to the _top_ of any "block", "float" or
"line box" earlier in the source (further rules are provided in the case
of collapsing margins).
3. When floated left, it will position itself to the _left_ of its
"containing block" and when floated right, it will position itself to
the _right_ of its "containing block" (further rules are provided in the
case of collapsing margins).
[A "Containing Block" is a generated box for the content/descendants
and the containing block's behavior is determined by the "type" of box
generated.]
4. The special feature of a float is that any inline box content in the
"container box" will shift over to make room for the float.

Caveat: Although I "got it" when I wrote it, I find on re-reading that I
have to reference the spec (bad part: in several different chapters) to
see what I was talking about. So it needs quite a few more re-reads for me.

--
Gus

On 2008-04-10, Gus Richter <gusrichter@netscape.net> wrote:
[...]
> The following condenses the spec a little more in detail:
>
> 1. Any floated item will be out of the normal flow.
> 2. A float will position itself to the _top_ of any "block", "float" or
> "line box" earlier in the source (further rules are provided in the case
> of collapsing margins).

Not earlier in the source but up the tree.

It goes to the top of the current line box provided that putting it
there doesn't mean that the line breaks such that text before the float
ends up on the line box beneath it. In that case it goes at the top of
the next line box. Firefox 2 and IE always put it at the top of the next
line box anyway although this is technically wrong.

> 3. When floated left, it will position itself to the _left_ of its
> "containing block" and when floated right, it will position itself to
> the _right_ of its "containing block"

Yes, although it might not make it all the way to the left or right if
there are other floats already in the way.

> (further rules are provided in the case of collapsing margins).

Collapsing margins don't affect how far to the left or right it goes
(well not directly, although they might influence the position of other
floats).

[...]

> 4. The special feature of a float is that any inline box content in the
> "container box" will shift over to make room for the float.

Yes although the inline boxes don't have to be in the same container.

<div>
<tall float that sticks out of the bottom>
</div>
<div>
This text will shift over to make room for the float in the div
above.
</div>

Ben C wrote:
> On 2008-04-07, Gus Richter <gusrichter@netscape.net> wrote:
> [...]
>> In my examples, "wrapper" and "containing block" are two different things.
>> The "wrapper" is simply used to reposition the segment pairs. In your
>> examples in the link I mention above, you use headings to accomplish
>> this w/o wrappers.
>> The "containing block" is each one of the yellow boxes in every one of
>> your examples on the page linked above (yellow boxes in my examples as
>> well). It is a bit counter-intuitive in that normally a container comes
>> first in the markup, but in the case with floats, the "container block"
>> comes _after_ the float.
>
> No the containing block for a float is always above it in the document
> tree.

I was trying to say that it was counter-intuitive because in the
markup/source the normal would be to have the float come _second_ as:

<div id="shrink">
<div id="float">Some text and more</div>
Some text and some more to get a few more lines.
</div>

when compared to where the float comes _first_:

<div id="float">Some text and more</div>
<div id="shrink">Some text and some more to get a few more lines.</div>

--
Gus

Ben C wrote:
>>> The float sticks out of the bottom of the first P, but is stacked on
>>> top of the second P, even though the second P comes later in the
>>> document. Assume P has a non-transparent background in this example.
>> Even with a background color applied to the float in order to see it,
>
> Perhaps it will to give the <p>s also thick borders. The point is
> just that the float is stacked on top of the second P's background
> instead of going behind it.

I see the overlapping now.

--
Gus

dorayme wrote:
> In article <27adndj4i_Ugp2HanZ2dnUVZ_rrinZ2d@golden.net>,
> Gus Richter <gusrichter@netscape.net> wrote:
>
>> I note that on alt.html dorayme is responding to a question "DIV -
>> dynamic height" wherein she gives another variable on her referenced page:
>> <http://netweaver.com.au/floatHouse/page10.html>
>> That page should be included in this thread as well.
>> The terminology of nuclear family should be removed, however, and
>> replaced with "containg block" and "floats". IMHO of course.
>
> I am not sure about this Gus, it is really not quite specific enough to
> be useful on the phenomenon you have raised. (btw, I accept now that
> there are reasonable explanations for what goes on).

Because you're using the "normal intuitive" method on that page. Refer
to the other post where I gave:

> I was trying to say that it was counter-intuitive because in the
> markup/source the normal would be to have the float come _second_ as:
>
> <div id="shrink">
> <div id="float">Some text and more</div>
> Some text and some more to get a few more lines.
> </div>
>
> when compared to where the float comes _first_:
>
> <div id="float">Some text and more</div>
> <div id="shrink">Some text and some more to get a few more lines.</div>

--
Gus

On 2008-04-10, Gus Richter <gusrichter@netscape.net> wrote:
> Ben C wrote:
>> On 2008-04-07, Gus Richter <gusrichter@netscape.net> wrote:
>> [...]
>>> In my examples, "wrapper" and "containing block" are two different things.
>>> The "wrapper" is simply used to reposition the segment pairs. In your
>>> examples in the link I mention above, you use headings to accomplish
>>> this w/o wrappers.
>>> The "containing block" is each one of the yellow boxes in every one of
>>> your examples on the page linked above (yellow boxes in my examples as
>>> well). It is a bit counter-intuitive in that normally a container comes
>>> first in the markup, but in the case with floats, the "container block"
>>> comes _after_ the float.
>>
>> No the containing block for a float is always above it in the document
>> tree.
>
> I was trying to say that it was counter-intuitive because in the
> markup/source the normal would be to have the float come _second_ as:
>
> <div id="shrink">
> <div id="float">Some text and more</div>
> Some text and some more to get a few more lines.
> </div>
>
> when compared to where the float comes _first_:
>
> <div id="float">Some text and more</div>
> <div id="shrink">Some text and some more to get a few more lines.</div>

OK, but in these two examples the containing block for the float is
different. In the first one it's #shrink, in the second it's BODY or
whatever's immediately outside #float and #shrink.

The text in #shrink flows around the float, but that doesn't mean it
shares the float's containing block.

Floats often overflow their containers vertically and any inlines that
are in the way have to get out of the way, regardless of whose
containing block they are in.

The damage caused by a float is however restricted to its block
formatting context (often higher up the tree than the local containing
block).

Ben C wrote:
> On 2008-04-10, Gus Richter <gusrichter@netscape.net> wrote:
>> Ben C wrote:
>>> On 2008-04-07, Gus Richter <gusrichter@netscape.net> wrote:
>>> [...]
>>>> In my examples, "wrapper" and "containing block" are two different things.
>>>> The "wrapper" is simply used to reposition the segment pairs. In your
>>>> examples in the link I mention above, you use headings to accomplish
>>>> this w/o wrappers.
>>>> The "containing block" is each one of the yellow boxes in every one of
>>>> your examples on the page linked above (yellow boxes in my examples as
>>>> well). It is a bit counter-intuitive in that normally a