Float and Shrinkwrap

On 2008-04-04, Gus Richter <gusrichter (AT) netscape (DOT) 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 (AT) spam_me_not (DOT) com> wrote:

dorayme wrote:
In article <MPWdnYQR98QBFWjanZ2dnUVZ_sednZ2d (AT) golden (DOT) net>,
Gus Richter <gusrichter (AT) netscape (DOT) 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 (AT) optusnet (DOT) 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 (AT) netscape (DOT) 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 (AT) netscape (DOT) 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 (AT) netscape (DOT) 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 (AT) netscape (DOT) 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 (AT) netscape (DOT) 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.