Float and Shrinkwrap

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. That is to say that the normal condition is that
the layers are normally not overlapping, but must be positioned by us to
make them overlap and only then can we fruitfully apply z-index to them.

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."

Additionally, <http://www.w3.org/TR/CSS21/visuren.html#propdef-z-index>
provides stacking levels for each stacking context.

Appendix E <http://www.w3.org/TR/CSS21/zindex.html> provides a more
thorough explanation of the stacking order.

Now it's just a matter of re-reading all to get it to sink in. :-)

--
Gus

In article <cv-dnTT7M6Kr3GranZ2dnUVZ_t2inZ2d (AT) golden (DOT) net>,
Gus Richter <gusrichter (AT) netscape (DOT) net> wrote:

dorayme wrote:

There is a 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. That is to say that the normal condition is that
the layers are normally not overlapping, but must be positioned by us to
make them overlap and only then can we fruitfully apply z-index to them.

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:

....

Additionally, <http://www.w3.org/TR/CSS21/visuren.html#propdef-z-index
provides stacking levels for each stacking context.

Appendix E <http://www.w3.org/TR/CSS21/zindex.html> provides a more
thorough explanation of the stacking order.

Now it's just a matter of re-reading all to get it to sink in. :-)

"Just" indeed!

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.

--
dorayme

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.

--
Gus

Gus Richter 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.

I'm still playing around with this and I thought I would share this one:
<http://www.home.golden.net/~richterf/Stuff/tst_2.html>

--
Gus

In article <bOqdnSlF-PAHC2TanZ2dnUVZ_t7inZ2d (AT) golden (DOT) net>,
Gus Richter <gusrichter (AT) netscape (DOT) net> wrote:

Gus Richter 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.

I'm still playing around with this and I thought I would share this one:
http://www.home.golden.net/~richterf/Stuff/tst_2.html

There is no doubt about what we see in various browsers.

I am still thinking about the float rules and the z-index rules and
Appendix E. I am not as optimistic about the determination of these
rules as you have appeared. But I am glad you are making me think about
it. (I rarely use either rel positioning or z-indexing in any commercial
work. Perhaps I should!)

Here is me again harping about terminology. (I have this idea that it is
quite important to be very clear and accurate in these matters). You
refer to a div that follows the float in the html as a containing block.
In a sense all divs are this in that they contain things or can. The
wrapper you have also contains things, here they contain the float and
the non-float divs. They don't seem to be doing anything useful here.
The body already is a container for all examples.

Firefox 2 on my Mac does respond to negative z-indexing btw.

--
dorayme

dorayme wrote:

Here is me again harping about terminology. (I have this idea that it is
quite important to be very clear and accurate in these matters). You
refer to a div that follows the float in the html as a containing block.

The spec refers to it as such. I used to refer to it, for my own
comprehension and because of lack of a proper name, as the "float box".
I believe that they refer to it simply as the "containing block"
because it contains and constrains (to 0,0) the float (mostly, since we
know that it can and will, also contain line boxes).

In a sense all divs are this in that they contain things or can. The
wrapper you have also contains things, here they contain the float and
the non-float divs. They don't seem to be doing anything useful here.

To be honest, it was an easy way to make it all work with all the
divs. No problem in that. I have thought about checking-for and
reducing-any redundant markup. This is what I now come up with:
The "wrapper" is used to wrap and separate each group for an easy way
to position/offset each group with a margin-top declaration.
The 1st "wrapper" may be removed and the margin applied directly to
the containing block it is true, but the next two, since they are
relatively positioned, won't work as easily. Try it. The float does not
follow.
Of course the float and shrink divs are mainly needed/used to give the
background colours.

The body already is a container for all examples.

Right, but to apply properties to a section, divisions come in handy.

Firefox 2 on my Mac does respond to negative z-indexing btw.

Mac/Firefox 2 is better than Win/Firefox 2, I guess. ;-)

--
Gus

In article <c_SdneNyX7EEKmTanZ2dnUVZ_gWdnZ2d (AT) golden (DOT) net>,
Gus Richter <gusrichter (AT) netscape (DOT) net> wrote:

dorayme wrote:

Here is me again harping about terminology. (I have this idea that it is
quite important to be very clear and accurate in these matters). You
refer to a div that follows the float in the html as a containing block.

The spec refers to it as such. I used to refer to it, for my own
comprehension and because of lack of a proper name, as the "float box".
I believe that they refer to it simply as the "containing block"
because it contains and constrains (to 0,0) the float (mostly, since we
know that it can and will, also contain line boxes).

In a sense all divs are this in that they contain things or can. The
wrapper you have also contains things, here they contain the float and
the non-float divs. They don't seem to be doing anything useful here.

To be honest, it was an easy way to make it all work with all the
divs. No problem in that. I have thought about checking-for and
reducing-any redundant markup. This is what I now come up with:
The "wrapper" is used to wrap and separate each group for an easy way
to position/offset each group with a margin-top declaration.
The 1st "wrapper" may be removed and the margin applied directly to
the containing block it is true, but the next two, since they are
relatively positioned, won't work as easily. Try it. The float does not
follow.
Of course the float and shrink divs are mainly needed/used to give the
background colours.

The body already is a container for all examples.

Right, but to apply properties to a section, divisions come in handy.

Firefox 2 on my Mac does respond to negative z-indexing btw.

Mac/Firefox 2 is better than Win/Firefox 2, I guess. ;-)

I guess we have been through a few of these things earlier. I put up an
example to strip all the things that I thought were not necessary to
show the interesting thing you are raising but I don't think you are too
impressed with this! I guess we think differently, I find it helps to
get rid of things I see as not relevant to the issue like wrappers to
each pair of divs, which wrappers are not given any relevant css, widths
that do not affect the basics and so on. This is not meant as some sort
of invasion of your stuff, all I can do is say what I find clear and
what not and hope you understand.

I am not keen on using any phrase printed by others (including the css
specs) if it does not signify something to me in my understanding.

I am inclined to actually use the phrase "containing block" where the
context shows it to do a job of containing. Your containing blocks don't
contain anything obvious (except their own text or pictures, a sense in
which most elements are containers). You seem not to be referring to
what you are calling wrappers. Here is an example of mine still on a
server where I use the the phrase:

<http://netweaver.com.au/alt/positionRelative.html>

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. I put up this
example just to make a terminological point, not to go into the subject
of that example.

More uses of this notion are in

<http://netweaver.com.au/floatHouse>

I am particularly interested in some of the things you are raising and
am meaning to add a few pages to the latter on this subject. But not
till I get clearer on it.

So far I have got to making:

<http://netweaver.com.au/alt/visibleOrder.html>

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>

The black is merely the bg to the float, the height to the float is
merely to show this bg. Heading css is irrelevant and only to lay out
the page a bit neatly.

My examples are not that different to yours and address my own pedantic
mind on this. I am beginning to form a better picture of all this stuff
and thanks for raising it Gus.

--
dorayme

dorayme wrote:

I guess we have been through a few of these things earlier. I put up an
example to strip all the things that I thought were not necessary to
show the interesting thing you are raising but I don't think you are too
impressed with this! I guess we think differently, I find it helps to
get rid of things I see as not relevant to the issue like wrappers to
each pair of divs, which wrappers are not given any relevant css, widths
that do not affect the basics and so on. This is not meant as some sort
of invasion of your stuff, all I can do is say what I find clear and
what not and hope you understand.

I didn't want the focus removed from my example initially since I had a
question still unanswered at the time as presented in my example. I am
not encumbered by some of the 'not relevant things' since they were
there to assist in visually presenting how I see things. I have no
problem with your examples as in:
<http://netweaver.com.au/alt/visibleOrder.html> which I think present
the same thing from a slightly different visual view.

I am not keen on using any phrase printed by others (including the css
specs) if it does not signify something to me in my understanding.

I am inclined to actually use the phrase "containing block" where the
context shows it to do a job of containing. Your containing blocks don't
contain anything obvious (except their own text or pictures, a sense in
which most elements are containers). You seem not to be referring to
what you are calling wrappers.

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. The "container block" contains the float (which
is set to 0,0 of the container block) and line box(es) which are shifted
to the right of the float. It is perhaps also counter-intuitive because
it does not appear in the markup but is an auto-creation by the
appearance of a float - a special feature of the float.

I wanted to answer some more to other points below, but have run out of
time. Must do other things today. The meat is in the above anyway. I
like your examples.

--
Gus

In article <NpydnewRWJVRs2fanZ2dnUVZ_rmjnZ2d (AT) golden (DOT) net>,
Gus Richter <gusrichter (AT) netscape (DOT) net> wrote:

dorayme wrote:

I guess we have been through a few of these things earlier. I put up an
....
I have no
problem with your examples as in:
http://netweaver.com.au/alt/visibleOrder.html> which I think present
the same thing from a slightly different visual view.

I am inclined to actually use the phrase "containing block" where the
context shows it to do a job of containing. Your containing blocks don't
contain anything obvious (except their own text or pictures, a sense in
which most elements are containers).


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).

Yes, I was gathering that.

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.

I think it is counter intuitive talk because it is not containing the
elements we are interested in as children.

The "container block" contains the float ... [this "container"]
is an auto-creation by the
appearance of a float - a special feature of the float.

I am seeing what you are referring to fine, but it looks like a
confusing way of expressing the facts. In fact, it looks like a slight
misunderstanding. The float is *not* contained by what you are calling a
"container" except in the most superficial way. If you actually use some
the positioning facilities in css available (either on the float via
margins or on the rel pos'd div, you will see this. It is just an
accident of the conditions that that they seem so intimate! They are
independent beings with complex relations! That's how I see it, anyway.
See the bottom of the page now at

<http://netweaver.com.au/alt/visibleOrder.html>

Btw, notice how the float and/or the rel pos'd div behave in the last
two examples. In the one the float does not exert its magic pushing of
the contents in the following div, while in the other it still does even
though the div is way clear in appearance. Of course, it is just the
appearance. As if float still thinks the div is where it was before it
was offset and thinks the div is an appropriate object to cast its spell
on (the spell being the float rules that push content aside in
non-floats). All this is reasonably clear from the float rules and the
nature of rel positioning.

It is a wonderful world of magic! I say we must pay due reverence to it
with careful terminology that seeks to talk of the deeper underlying
structures.

As for the particular business of visual layering, I will have more to
say on this later. It is an absolutely abominable scheme even though it
is easy enough to get about it in a practical way. Even to learn 'the
rules'. I definitely don't think the authors of the visual layering
model in CSS have created a wonder of the world. It may well be that the
task was so difficult that only abominations were practical.

I wanted to answer some more to other points below, but have run out of
time. Must do other things today. The meat is in the above anyway. I
like your examples.

No worries. I will just get a slab[1] of beers from the fridge and get
rotten drunk to pass the time till you get back from work.

-------------
1. A slab of beers in Australia is a cardboard pack of 24 tinnies. These
are half the size of long-necks (750 ml).

--
dorayme

dorayme wrote:

I am seeing what you are referring to fine, but it looks like a
confusing way of expressing the facts. In fact, it looks like a slight
misunderstanding. The float is *not* contained by what you are calling a
"container" except in the most superficial way.

Not sure if this will convince you away from the dark side, but try at
the end in the link below:
<img src="pics/floatA.jpg" alt="" height="50" width="75"
style="float:left;">Text following.
<div style="clear:both;margin-bottom:50px;"></div>
<img src="pics/floatA.jpg" alt="" height="50" width="75"
style="float:left;"><p>Text following.</p>
<div style="clear:both;margin-bottom:50px;"></div>
<p><img src="pics/floatA.jpg" alt="" height="50" width="75"
style="float:left;">Text following.</p>
<div style="clear:both;margin-bottom:50px;"></div>
Then try it with divs.
Then try positioning the divs. Prelim tests show that there appear to be
differences comparing those to these three.
All have the _same_ "containing block".
Hope you enjoy the new thing I've introduced here. ;-)

http://netweaver.com.au/alt/visibleOrder.html

Btw, notice how the float and/or the rel pos'd div behave in the last
two examples. In the one the float does not exert its magic pushing of
the contents in the following div, while in the other it still does even
though the div is way clear in appearance.

This is because in the one instance you displace the float and the
real estate it had occupied before is retained.
In the other you displace the containing block and the inline box
content in the containing block does not have to shift over to make room
for the float which is no longer in the way.

No worries. I will just get a slab[1] of beers from the fridge and get
rotten drunk to pass the time till you get back from work.

Heard about you Aussies. LOL. Used to have ads on TV here for Fosters Beer.

--
Gus