Float and Shrinkwrap

03/04/2008, 16h56

A floated element basically is stacked on top of the subsequent
shrinkwrapping element.
If the shrinkwrap is given position:relative then this stacking order
is reversed.
Why is this reversal in stacking order?

--
Gus

04/04/2008, 02h47

dorayme wrote:

> modify to show what you are wondering about. Sounds interesting Gus
> but there are so many things you could be referring to?

All is in the following:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<title>Test</title>
<style type="text/css" media="all">
#shrink {border: 1px solid;background: #ffc;width:8em;}
#float {float: left; border: 1px solid; background: #cfc;width:4em;}

#wrapper {margin-top:250px;}
#shrink_1 {border: 1px solid;background: #ffc;width:8em; position:relative;}
#float_1 {float: left; border: 1px solid; background: #cfc;width:4em;}

#wrapper_2 {margin-top:50px;}
#shrink_2 {border: 1px solid;width:8em; position:relative;}
#float_2 {float: left; border: 1px solid; background: #cfc;width:4em;}

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

<div style="position:absolute;top:50px;left:200px;width :400px;border:2px
solid

adding:6px;background

range;">
<p>
"Assume" #float to be positioned at top:0;left:0; - then #shrink (the
shrinkwrap box) is also at top:0;left:0;</p>
<p>So the floated element (#float) basically is stacked on top of the
subsequent shrinkwrapping element (#shrink).<br>
If the shrinkwrap is given position:relative then this stacking order
is reversed. [see example 2] - #float is behind #shrink and

therefore is covered (hidden).<br>
<span style="color:red;">Why is this reversal in stacking order?</span></p>

<p>Example 3 is the same as example 2 except the shrinkwrapping element
(#shrink) has its background removed - #float is still behind

#shrink but now we can see the float again since its no longer covered.</p>
</div>

<div id="wrapper">
<div id="float_1">Some text and more</div>
<div id="shrink_1">Some text and some more to get a few more lines.</div>
</div>

<div id="wrapper_2">
<div id="float_2">Some text and more</div>
<div id="shrink_2">Some text and some more to get a few more lines.</div>
</div>

</body>
</html>

04/04/2008, 03h38

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.

Jeff

(I used the id to try to interpret what you meant by
> styling it with something that is normally associated with the idea of
> shrinkwrapping. You drop this. Giving a div a width is not "shrink"
> wrapping it.)
>

04/04/2008, 04h00

dorayme wrote:
> In article <MsGdndQCEoMuCWjanZ2dnUVZ_rzinZ2d@earthlink.com> ,
> Jeff <jeff@spam_me_not.com> wrote:
>
>> Something about floats shrinking to the minimum size of the contents,
>> again something I'm unfamiliar with.
>
> A float sizes itself to the content. Just see by giving a float a border
> and varying text.
>
> But not an ordinary div that is given a width.

The subsequent text wraps around the float like shrinkwrapping paper
does. You obviously don't spend much time in the kitchen.

--
Gus

04/04/2008, 04h04

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" (I used the id to try to interpret what you meant by
> styling it with something that is normally associated with the idea of
> shrinkwrapping. You drop this. Giving a div a width is not "shrink"
> wrapping it.)

#shrink is not being shrinkwrapped. It does the shrinkwrapping. #float
is what is being shrinkwrapped by #shrink.

I won't use the term any more if it is confusing.

--
Gus

04/04/2008, 05h31

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?_
3. Example 3 is the same as the second example except background is
removed from #shrink. #float is still behind #shrink but can be
seen. Example 3 is only to show what's behind and in front.

I hope that this is clearer. BTW, I believe that I understand floats
very well and the examples are clean and simple. Once we get past this,
there is only the stacking order with my _Why?_ remaining, with Firefox,
Opera and Safari behaving the same.

~~~~~~~~
In a shipping environment, the item to be shipped may be shrinkwrapped.
This procedure does not alter the size of the item. The method I have
seen uses foam material which expands to envelop the item and takes on
the form of the item, padding the item within the cardboard box, ready
for shipping. The first I saw was shrink-tubing which under heat would
contract tightly over the item. I used this to insulate soldered wire
joints. Size of the item (relate this to the float) does not change,
only the shrinkwrapping goes around the item (relate this to the _text_
within div#shrink).

The kitchen part is thinking of the cellophane stretchable material
which you can use to wrap your vegetables, etc. to protect and keep
fresh. It also kind of shrinkwraps around the item.

If this is still unclear, then back to Appendix E.

--
Gus
Hey, it's the way my mind works. And it works - at times.

04/04/2008, 05h52

dorayme wrote:
> In article
> <doraymeRidThis-A8B9E4.14270204042008@news-vip.optusnet.com.au>,
> dorayme <doraymeRidThis@optusnet.com.au> wrote:
>
>> In article <Gc2dnQtbW8ZTB2janZ2dnUVZ_qygnZ2d@golden.net>,
>> Gus Richter <gusrichter@netscape.net> wrote:
>>
>>> I won't use the term any more if it is confusing.
>
> I think your question boils down to why the difference between the 2nd
> and 3rd of:
>
> <http://netweaver.com.au/alt/visibleOrder.html>

Well, we could talk about your re-do, but why not mine?
Any way, your re-do has background:transparent; on the div which should
be on the float the 3rd time it's used in the example.

The question as posed before and here as well:
In the 2nd line, why does the float move to the back behind the div once
position:relative; is applied to the div?

--
Gus

04/04/2008, 05h56

dorayme wrote:
> In article <ocednXRAqO-WMmjanZ2dnUVZ_h6hnZ2d@golden.net>,
> Gus Richter <gusrichter@netscape.net> wrote:
>
>> No! The dimensions are needed! As is! In my examples!
>
> Gus. I am not saying you should not have the widths for some other
> purposes of your own! Have them! They are yours. I am happy you should
> have them. Really.
>
> I am only saying that that there is an interesting question about the
> visibility that has *nothing whatsoever* to do with your widths or any
> consequence of your widths. And it seems to me to be your essential
> question. See the url I gave before.
>
> <http://netweaver.com.au/alt/visibleOrder.html>
>
> The question still remains without the widths. Agree?

Yes I agree. I set it up like I did in order to make it clear and
simple. Boy was I wrong. I re-did the question to your example.

--
Gus

04/04/2008, 22h06

Gus Richter wrote:
> A floated element basically is stacked on top of the subsequent
> shrinkwrapping element.
> If the shrinkwrap is given position:relative then this stacking order
> is reversed.
> Why is this reversal in stacking order?

Anyone care to look into this deeper, follow the link to my examples:
<http://www.home.golden.net/~richterf/Stuff/tst.html>

--
Gus

04/04/2008, 22h23

dorayme wrote:
>
> The float rules do not appear to me to explain why a div that is given a
> relative positioning (albeit with no offsets) should have its background
> behave this way to cover a float.

I see that you do understand my question after all.

~~~~ snipped a lot of stuff ~~~~

Not sure what to make of your writings (wanderings/thoughts?).
At times it sounds serious.

See my new example with a new 'red herring' added. Jeez.

--
Gus

05/04/2008, 01h34

Gus Richter wrote:
> Gus Richter wrote:
>> A floated element basically is stacked on top of the subsequent
>> shrinkwrapping element.
>> If the shrinkwrap is given position:relative then this stacking
>> order is reversed.
>> Why is this reversal in stacking order?
>
> Anyone care to look into this deeper, follow the link to my examples:
> <http://www.home.golden.net/~richterf/Stuff/tst.html>

OK, it's simply a case of "Stacking Order" after all.
Here is another page with an additional example:
<http://www.home.golden.net/~richterf/Stuff/tst_1.html>

Note that Opera and Safari get it right.
Mozilla might get it right in version 3, dunno I have 2.0.0.13

--
Gus

05/04/2008, 05h49

dorayme wrote:
> In article <i8GdnTQCba2JVGvanZ2dnUVZ_iydnZ2d@golden.net>,
> Gus Richter <gusrichter@netscape.net> wrote:
>
>> OK, it's simply a case of "Stacking Order" after all.
>
> Simply eh? I wish I could see it as simple.

Firefox 3 beta 5 gets it right as well.

--
Gus

05/04/2008, 10h07

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

06/04/2008, 15h34

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

07/04/2008, 04h35

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

07/04/2008, 06h56

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

07/04/2008, 15h25

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 s 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

08/04/2008, 05h32

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

08/04/2008, 05h44

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

--
Gus

08/04/2008, 05h57

Gus Richter <gusrichter@netscape.net> wrote in
news:WoOdnYR9Y7aBZWfanZ2dnUVZ_gKdnZ2d@golden.net:

> 2. When floated left, it will position itself to top,left (0,0) of its
> "container block".

http://www.w3.org/TR/CSS21/visuren.html#floats

When floated left it will be shifted to the left until its outer edge
touches the containing block edge or the outer edge of another float. If
there is a line box the top of the floated box is aligned with the top of
the current line box. This will usually not be the top of the container
block.

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

08/04/2008, 06h15

rf wrote:
> Gus Richter <gusrichter@netscape.net> wrote in
> news:WoOdnYR9Y7aBZWfanZ2dnUVZ_gKdnZ2d@golden.net:
>
>> 2. When floated left, it will position itself to top,left (0,0) of its
>> "container block".
>
> http://www.w3.org/TR/CSS21/visuren.html#floats
>
> When floated left it will be shifted to the left until its outer edge
> touches the containing block edge or the outer edge of another float. If
> there is a line box the top of the floated box is aligned with the top of
> the current line box. This will usually not be the top of the container
> block.

Funny thing is that when I read it, it says:
A floated box is shifted to the left or right until its outer edge
touches the containing block edge or the outer edge of another float.
If there's a line box, the top of the floated box is aligned with the
top of the current line box.

What makes you add the last sentence in your quote?

--
Gus

08/04/2008, 06h28

dorayme wrote:
> In article <ScudnU3ayMXRaGfanZ2dnUVZ_gadnZ2d@golden.net>,
> Gus Richter <gusrichter@netscape.net> wrote:
>
>> Not sure if this will convince you away from the dark side
>
> ?

I guess you're too young to remember Star Wars.

>> This is because in the one instance you displace the float and the
>> real estate it had occupied before is retained.
>
> I was not the least puzzled by the examples at the end. They were not
> offered as something to be explained but to make a point about
> terminology.

Sorry, but "this is reasonably clear" made me think otherwise.

--
Gus

08/04/2008, 06h32

Gus Richter <gusrichter@netscape.net> wrote in
news:mtmdnc-aIeb5YmfanZ2dnUVZ_hadnZ2d@golden.net:

> rf wrote:
>> Gus Richter <gusrichter@netscape.net> wrote in
>> news:WoOdnYR9Y7aBZWfanZ2dnUVZ_gKdnZ2d@golden.net:
>>
>>> 2. When floated left, it will position itself to top,left (0,0) of
>>> its "container block".
>>
>> http://www.w3.org/TR/CSS21/visuren.html#floats
>>
>> When floated left it will be shifted to the left until its outer edge
>> touches the containing block edge or the outer edge of another float.
>> If there is a line box the top of the floated box is aligned with the
>> top of the current line box. This will usually not be the top of the
>> container block.
>
> Funny thing is that when I read it, it says:
> A floated box is shifted to the left or right until its outer edge
> touches the containing block edge or the outer edge of another
> float. If there's a line box, the top of the floated box is aligned
> with the top of the current line box.
>
> What makes you add the last sentence in your quote?

The quoted, or rather restated, text is incomplete and therefore
misleading. I added that last sentence to clarify matters.

<body>
<p>
a very long paragraph that causes lots of line boxes to be generated a
very long paragraph that causes lots of line boxes to be generated a very
long paragraph that causes lots of line boxes to be generated a very long
paragraph that causes lots of line boxes to be generated a very long
paragraph that causes lots of line boxes to be generated a very long
paragraph that causes lots of line boxes to be generated a very long
paragraph that causes lots of line boxes to be generated a very long
paragraph that causes lots of line boxes to be generated a very long
paragraph that causes lots of line boxes to be generated the last text
before the image <img src=... style='float: left'> a bit more text
</p>
</body>

There will be quite a number of line boxes before the image is
encountered. The image will be floated to the left of the containing
block but the top of the image will be aligned with the top of the line
box that contains the text 'the last text before the image' or
thereabouts, depending on how the text is wrapped. This is nowhere near
the top of the containing box.

If you follow the above link and then scroll down a bit you will find an
illustration where a floated element overlaps two paragraphs. The caption
is "A floating image obscures borders ..." Note that the top of the
floated element is not at the top of the first paragraph. It is at the
top of the second line block. Look closely at the text, looking for the
(X).

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

08/04/2008, 06h40

dorayme wrote:
>
> 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 (much like
> some of your examples with wrappers). You seem to favour the container
> word to refer to the following (html order) sibling after the float.

I use the term "container block" because it is the one used in the
specs. I mentioned in an earlier post that I think of it more as "float
box" because it is a special thing just for floats.

You wish to see it in the more conventional way of something inside a
"container" as in a non-float situation. Please try the latest that I
posted right after mentioning the "dark side". They are constructed in
the conventional way.

--
Gus

08/04/2008, 07h09

rf wrote:
> Gus Richter <gusrichter@netscape.net> wrote in
> news:mtmdnc-aIeb5YmfanZ2dnUVZ_hadnZ2d@golden.net:
>
>> rf wrote:
>>> Gus Richter <gusrichter@netscape.net> wrote in
>>> news:WoOdnYR9Y7aBZWfanZ2dnUVZ_gKdnZ2d@golden.net:
>>>
>>>> 2. When floated left, it will position itself to top,left (0,0) of
>>>> its "container block".
>>> http://www.w3.org/TR/CSS21/visuren.html#floats
>>>
>>> When floated left it will be shifted to the left until its outer edge
>>> touches the containing block edge or the outer edge of another float.
>>> If there is a line box the top of the floated box is aligned with the
>>> top of the current line box. This will usually not be the top of the
>>> container block.
>> Funny thing is that when I read it, it says:
>> A floated box is shifted to the left or right until its outer edge
>> touches the containing block edge or the outer edge of another
>> float. If there's a line box, the top of the floated box is aligned
>> with the top of the _current_ line box.
>>
>> What makes you add the last sentence in your quote?
>
> The quoted, or rather restated, text is incomplete and therefore
> misleading. I added that last sentence to clarify matters.
>
> <body>
> <p>
> a very long paragraph that causes lots of line boxes to be generated a
> very long paragraph that causes lots of line boxes to be generated a very
> long paragraph that causes lots of line boxes to be generated a very long
> paragraph that causes lots of line boxes to be generated a very long
> paragraph that causes lots of line boxes to be generated a very long
> paragraph that causes lots of line boxes to be generated a very long
> paragraph that causes lots of line boxes to be generated a very long
> paragraph that causes lots of line boxes to be generated a very long
> paragraph that causes lots of line boxes to be generated the last text
> before the image <img src=... style='float: left'> a bit more text
> </p>
> </body>
>
> There will be quite a number of line boxes before the image is
> encountered. The image will be floated to the left of the containing
> block but the top of the image will be aligned with the top of the line
> box that contains the text 'the last text before the image' or
> thereabouts, depending on how the text is wrapped. This is nowhere near
> the top of the containing box.
>
> If you follow the above link and then scroll down a bit you will find an
> illustration where a floated element overlaps two paragraphs. The caption
> is "A floating image obscures borders ..." Note that the top of the
> floated element is not at the top of the first paragraph. It is at the
> top of the second line block. Look closely at the text, looking for the
> (X).

You are absolutely right about what you say. The spec does cover this
(highlighted by me in the quote above) by saying that it is aligned to
the top of the _current_ line box.

The mistake is mine. We've been using only one and not multiple
instances as you have pointed out. I've been referring to our examples
only without thinking about other variables. Thank you for pointing this
out. I do not profess to be an expert and expect to be corrected.

I do, however, have an issue with correcting the spec since it is
correct in this instance and the correction should be in my statement:

2. When floated left, it will position itself to top,left (0,0) of its
"container block".

which should be corrected to:

2. When floated left, it will position itself to the left of its
"container block" and to the top of the current line box. In the
instance where the float is presented initially, or there is only
one line box, the top of the container block is the same as the
top of the first line box.

I hope that this is OK? I was not trying to rewrite the specs, but just
trying to explain my understanding of the float.

--
Gus

03/04/2008, 16h56	#1
Gus Richter Messages: n/a Hébergeur:	Float and Shrinkwrap A floated element basically is stacked on top of the subsequent shrinkwrapping element. If the shrinkwrap is given position:relative then this stacking order is reversed. Why is this reversal in stacking order? -- Gus

04/04/2008, 02h47	#2
Gus Richter Messages: n/a Hébergeur:	Re: Float and Shrinkwrap dorayme wrote: > modify to show what you are wondering about. Sounds interesting Gus > but there are so many things you could be referring to? All is in the following: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <html> <head> <title>Test</title> <style type="text/css" media="all"> #shrink {border: 1px solid;background: #ffc;width:8em;} #float {float: left; border: 1px solid; background: #cfc;width:4em;} #wrapper {margin-top:250px;} #shrink_1 {border: 1px solid;background: #ffc;width:8em; position:relative;} #float_1 {float: left; border: 1px solid; background: #cfc;width:4em;} #wrapper_2 {margin-top:50px;} #shrink_2 {border: 1px solid;width:8em; position:relative;} #float_2 {float: left; border: 1px solid; background: #cfc;width:4em;} </style> </head> <body> <div id="float">Some text and more</div> <div id="shrink">Some text and some more to get a few more lines.</div> <div style="position:absolute;top:50px;left:200px;width :400px;border:2px solidadding:6px;backgroundrange;"> <p> "Assume" #float to be positioned at top:0;left:0; - then #shrink (the shrinkwrap box) is also at top:0;left:0;</p> <p>So the floated element (#float) basically is stacked on top of the subsequent shrinkwrapping element (#shrink).<br> If the shrinkwrap is given position:relative then this stacking order is reversed. [see example 2] - #float is behind #shrink and therefore is covered (hidden).<br> <span style="color:red;">Why is this reversal in stacking order?</span></p> <p>Example 3 is the same as example 2 except the shrinkwrapping element (#shrink) has its background removed - #float is still behind #shrink but now we can see the float again since its no longer covered.</p> </div> <div id="wrapper"> <div id="float_1">Some text and more</div> <div id="shrink_1">Some text and some more to get a few more lines.</div> </div> <div id="wrapper_2"> <div id="float_2">Some text and more</div> <div id="shrink_2">Some text and some more to get a few more lines.</div> </div> </body> </html>

04/04/2008, 03h38	#3
Jeff Messages: n/a Hébergeur:	Re: Float and Shrinkwrap 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. Jeff (I used the id to try to interpret what you meant by > styling it with something that is normally associated with the idea of > shrinkwrapping. You drop this. Giving a div a width is not "shrink" > wrapping it.) >

04/04/2008, 04h00	#4
Gus Richter Messages: n/a Hébergeur:	Re: Float and Shrinkwrap dorayme wrote: > In article <MsGdndQCEoMuCWjanZ2dnUVZ_rzinZ2d@earthlink.com> , > Jeff <jeff@spam_me_not.com> wrote: > >> Something about floats shrinking to the minimum size of the contents, >> again something I'm unfamiliar with. > > A float sizes itself to the content. Just see by giving a float a border > and varying text. > > But not an ordinary div that is given a width. The subsequent text wraps around the float like shrinkwrapping paper does. You obviously don't spend much time in the kitchen. -- Gus

04/04/2008, 04h04	#5
Gus Richter Messages: n/a Hébergeur:	Re: Float and Shrinkwrap 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" (I used the id to try to interpret what you meant by > styling it with something that is normally associated with the idea of > shrinkwrapping. You drop this. Giving a div a width is not "shrink" > wrapping it.) #shrink is not being shrinkwrapped. It does the shrinkwrapping. #float is what is being shrinkwrapped by #shrink. I won't use the term any more if it is confusing. -- Gus

04/04/2008, 05h31	#6
Gus Richter Messages: n/a Hébergeur:	Re: Float and Shrinkwrap 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?_ 3. Example 3 is the same as the second example except background is removed from #shrink. #float is still behind #shrink but can be seen. Example 3 is only to show what's behind and in front. I hope that this is clearer. BTW, I believe that I understand floats very well and the examples are clean and simple. Once we get past this, there is only the stacking order with my _Why?_ remaining, with Firefox, Opera and Safari behaving the same. ~~~~~~~~ In a shipping environment, the item to be shipped may be shrinkwrapped. This procedure does not alter the size of the item. The method I have seen uses foam material which expands to envelop the item and takes on the form of the item, padding the item within the cardboard box, ready for shipping. The first I saw was shrink-tubing which under heat would contract tightly over the item. I used this to insulate soldered wire joints. Size of the item (relate this to the float) does not change, only the shrinkwrapping goes around the item (relate this to the _text_ within div#shrink). The kitchen part is thinking of the cellophane stretchable material which you can use to wrap your vegetables, etc. to protect and keep fresh. It also kind of shrinkwraps around the item. If this is still unclear, then back to Appendix E. -- Gus Hey, it's the way my mind works. And it works - at times.

04/04/2008, 05h52	#7
Gus Richter Messages: n/a Hébergeur:	Re: Float and Shrinkwrap dorayme wrote: > In article > <doraymeRidThis-A8B9E4.14270204042008@news-vip.optusnet.com.au>, > dorayme <doraymeRidThis@optusnet.com.au> wrote: > >> In article <Gc2dnQtbW8ZTB2janZ2dnUVZ_qygnZ2d@golden.net>, >> Gus Richter <gusrichter@netscape.net> wrote: >> >>> I won't use the term any more if it is confusing. > > I think your question boils down to why the difference between the 2nd > and 3rd of: > > <http://netweaver.com.au/alt/visibleOrder.html> Well, we could talk about your re-do, but why not mine? Any way, your re-do has background:transparent; on the div which should be on the float the 3rd time it's used in the example. The question as posed before and here as well: In the 2nd line, why does the float move to the back behind the div once position:relative; is applied to the div? -- Gus

04/04/2008, 05h56	#8
Gus Richter Messages: n/a Hébergeur:	Re: Float and Shrinkwrap dorayme wrote: > In article <ocednXRAqO-WMmjanZ2dnUVZ_h6hnZ2d@golden.net>, > Gus Richter <gusrichter@netscape.net> wrote: > >> No! The dimensions are needed! As is! In my examples! > > Gus. I am not saying you should not have the widths for some other > purposes of your own! Have them! They are yours. I am happy you should > have them. Really. > > I am only saying that that there is an interesting question about the > visibility that has nothing whatsoever to do with your widths or any > consequence of your widths. And it seems to me to be your essential > question. See the url I gave before. > > <http://netweaver.com.au/alt/visibleOrder.html> > > The question still remains without the widths. Agree? Yes I agree. I set it up like I did in order to make it clear and simple. Boy was I wrong. I re-did the question to your example. -- Gus

04/04/2008, 22h06	#9
Gus Richter Messages: n/a Hébergeur:	Re: Float and Shrinkwrap Gus Richter wrote: > A floated element basically is stacked on top of the subsequent > shrinkwrapping element. > If the shrinkwrap is given position:relative then this stacking order > is reversed. > Why is this reversal in stacking order? Anyone care to look into this deeper, follow the link to my examples: <http://www.home.golden.net/~richterf/Stuff/tst.html> -- Gus

04/04/2008, 22h23	#10
Gus Richter Messages: n/a Hébergeur:	Re: Float and Shrinkwrap dorayme wrote: > > The float rules do not appear to me to explain why a div that is given a > relative positioning (albeit with no offsets) should have its background > behave this way to cover a float. I see that you do understand my question after all. ~~~~ snipped a lot of stuff ~~~~ Not sure what to make of your writings (wanderings/thoughts?). At times it sounds serious. See my new example with a new 'red herring' added. Jeez. -- Gus

05/04/2008, 01h34	#11
Gus Richter Messages: n/a Hébergeur:	Re: Float and Shrinkwrap Gus Richter wrote: > Gus Richter wrote: >> A floated element basically is stacked on top of the subsequent >> shrinkwrapping element. >> If the shrinkwrap is given position:relative then this stacking >> order is reversed. >> Why is this reversal in stacking order? > > Anyone care to look into this deeper, follow the link to my examples: > <http://www.home.golden.net/~richterf/Stuff/tst.html> OK, it's simply a case of "Stacking Order" after all. Here is another page with an additional example: <http://www.home.golden.net/~richterf/Stuff/tst_1.html> Note that Opera and Safari get it right. Mozilla might get it right in version 3, dunno I have 2.0.0.13 -- Gus

05/04/2008, 05h49	#12
Gus Richter Messages: n/a Hébergeur:	Re: Float and Shrinkwrap dorayme wrote: > In article <i8GdnTQCba2JVGvanZ2dnUVZ_iydnZ2d@golden.net>, > Gus Richter <gusrichter@netscape.net> wrote: > >> OK, it's simply a case of "Stacking Order" after all. > > Simply eh? I wish I could see it as simple. Firefox 3 beta 5 gets it right as well. -- Gus

05/04/2008, 10h07	#13
Gus Richter Messages: n/a Hébergeur:	Re: 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

06/04/2008, 15h34	#14
Gus Richter Messages: n/a Hébergeur:	Re: Float and Shrinkwrap 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

07/04/2008, 04h35	#15
Gus Richter Messages: n/a Hébergeur:	Re: Float and Shrinkwrap 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

07/04/2008, 06h56	#16
Gus Richter Messages: n/a Hébergeur:	Re: Float and Shrinkwrap 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

07/04/2008, 15h25	#17
Gus Richter Messages: n/a Hébergeur:	Re: Float and Shrinkwrap 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 s 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

08/04/2008, 05h32	#18
Gus Richter Messages: n/a Hébergeur:	Re: Float and Shrinkwrap 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

08/04/2008, 05h44	#19
Gus Richter Messages: n/a Hébergeur:	Re: Float and Shrinkwrap 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?" -- Gus

08/04/2008, 05h57	#20
rf Messages: n/a Hébergeur:	Re: Float and Shrinkwrap Gus Richter <gusrichter@netscape.net> wrote in news:WoOdnYR9Y7aBZWfanZ2dnUVZ_gKdnZ2d@golden.net: > 2. When floated left, it will position itself to top,left (0,0) of its > "container block". http://www.w3.org/TR/CSS21/visuren.html#floats When floated left it will be shifted to the left until its outer edge touches the containing block edge or the outer edge of another float. If there is a line box the top of the floated box is aligned with the top of the current line box. This will usually not be the top of the container block. -- Richard Killing all threads involving google groups The Usenet Improvement Project: http://improve-usenet.org

08/04/2008, 06h15	#21
Gus Richter Messages: n/a Hébergeur:	Re: Float and Shrinkwrap rf wrote: > Gus Richter <gusrichter@netscape.net> wrote in > news:WoOdnYR9Y7aBZWfanZ2dnUVZ_gKdnZ2d@golden.net: > >> 2. When floated left, it will position itself to top,left (0,0) of its >> "container block". > > http://www.w3.org/TR/CSS21/visuren.html#floats > > When floated left it will be shifted to the left until its outer edge > touches the containing block edge or the outer edge of another float. If > there is a line box the top of the floated box is aligned with the top of > the current line box. This will usually not be the top of the container > block. Funny thing is that when I read it, it says: A floated box is shifted to the left or right until its outer edge touches the containing block edge or the outer edge of another float. If there's a line box, the top of the floated box is aligned with the top of the current line box. What makes you add the last sentence in your quote? -- Gus

08/04/2008, 06h28	#22
Gus Richter Messages: n/a Hébergeur:	Re: Float and Shrinkwrap dorayme wrote: > In article <ScudnU3ayMXRaGfanZ2dnUVZ_gadnZ2d@golden.net>, > Gus Richter <gusrichter@netscape.net> wrote: > >> Not sure if this will convince you away from the dark side > > ? I guess you're too young to remember Star Wars. >> This is because in the one instance you displace the float and the >> real estate it had occupied before is retained. > > I was not the least puzzled by the examples at the end. They were not > offered as something to be explained but to make a point about > terminology. Sorry, but "this is reasonably clear" made me think otherwise. -- Gus

08/04/2008, 06h32	#23
rf Messages: n/a Hébergeur:	Re: Float and Shrinkwrap Gus Richter <gusrichter@netscape.net> wrote in news:mtmdnc-aIeb5YmfanZ2dnUVZ_hadnZ2d@golden.net: > rf wrote: >> Gus Richter <gusrichter@netscape.net> wrote in >> news:WoOdnYR9Y7aBZWfanZ2dnUVZ_gKdnZ2d@golden.net: >> >>> 2. When floated left, it will position itself to top,left (0,0) of >>> its "container block". >> >> http://www.w3.org/TR/CSS21/visuren.html#floats >> >> When floated left it will be shifted to the left until its outer edge >> touches the containing block edge or the outer edge of another float. >> If there is a line box the top of the floated box is aligned with the >> top of the current line box. This will usually not be the top of the >> container block. > > Funny thing is that when I read it, it says: > A floated box is shifted to the left or right until its outer edge > touches the containing block edge or the outer edge of another > float. If there's a line box, the top of the floated box is aligned > with the top of the current line box. > > What makes you add the last sentence in your quote? The quoted, or rather restated, text is incomplete and therefore misleading. I added that last sentence to clarify matters. <body> <p> a very long paragraph that causes lots of line boxes to be generated a very long paragraph that causes lots of line boxes to be generated a very long paragraph that causes lots of line boxes to be generated a very long paragraph that causes lots of line boxes to be generated a very long paragraph that causes lots of line boxes to be generated a very long paragraph that causes lots of line boxes to be generated a very long paragraph that causes lots of line boxes to be generated a very long paragraph that causes lots of line boxes to be generated a very long paragraph that causes lots of line boxes to be generated the last text before the image <img src=... style='float: left'> a bit more text </p> </body> There will be quite a number of line boxes before the image is encountered. The image will be floated to the left of the containing block but the top of the image will be aligned with the top of the line box that contains the text 'the last text before the image' or thereabouts, depending on how the text is wrapped. This is nowhere near the top of the containing box. If you follow the above link and then scroll down a bit you will find an illustration where a floated element overlaps two paragraphs. The caption is "A floating image obscures borders ..." Note that the top of the floated element is not at the top of the first paragraph. It is at the top of the second line block. Look closely at the text, looking for the (X). -- Richard Killing all threads involving google groups The Usenet Improvement Project: http://improve-usenet.org

08/04/2008, 06h40	#24
Gus Richter Messages: n/a Hébergeur:	Re: Float and Shrinkwrap dorayme wrote: > > 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 (much like > some of your examples with wrappers). You seem to favour the container > word to refer to the following (html order) sibling after the float. I use the term "container block" because it is the one used in the specs. I mentioned in an earlier post that I think of it more as "float box" because it is a special thing just for floats. You wish to see it in the more conventional way of something inside a "container" as in a non-float situation. Please try the latest that I posted right after mentioning the "dark side". They are constructed in the conventional way. -- Gus

08/04/2008, 07h09	#25
Gus Richter Messages: n/a Hébergeur:	Re: Float and Shrinkwrap rf wrote: > Gus Richter <gusrichter@netscape.net> wrote in > news:mtmdnc-aIeb5YmfanZ2dnUVZ_hadnZ2d@golden.net: > >> rf wrote: >>> Gus Richter <gusrichter@netscape.net> wrote in >>> news:WoOdnYR9Y7aBZWfanZ2dnUVZ_gKdnZ2d@golden.net: >>> >>>> 2. When floated left, it will position itself to top,left (0,0) of >>>> its "container block". >>> http://www.w3.org/TR/CSS21/visuren.html#floats >>> >>> When floated left it will be shifted to the left until its outer edge >>> touches the containing block edge or the outer edge of another float. >>> If there is a line box the top of the floated box is aligned with the >>> top of the current line box. This will usually not be the top of the >>> container block. >> Funny thing is that when I read it, it says: >> A floated box is shifted to the left or right until its outer edge >> touches the containing block edge or the outer edge of another >> float. If there's a line box, the top of the floated box is aligned >> with the top of the _current_ line box. >> >> What makes you add the last sentence in your quote? > > The quoted, or rather restated, text is incomplete and therefore > misleading. I added that last sentence to clarify matters. > > <body> > <p> > a very long paragraph that causes lots of line boxes to be generated a > very long paragraph that causes lots of line boxes to be generated a very > long paragraph that causes lots of line boxes to be generated a very long > paragraph that causes lots of line boxes to be generated a very long > paragraph that causes lots of line boxes to be generated a very long > paragraph that causes lots of line boxes to be generated a very long > paragraph that causes lots of line boxes to be generated a very long > paragraph that causes lots of line boxes to be generated a very long > paragraph that causes lots of line boxes to be generated the last text > before the image <img src=... style='float: left'> a bit more text > </p> > </body> > > There will be quite a number of line boxes before the image is > encountered. The image will be floated to the left of the containing > block but the top of the image will be aligned with the top of the line > box that contains the text 'the last text before the image' or > thereabouts, depending on how the text is wrapped. This is nowhere near > the top of the containing box. > > If you follow the above link and then scroll down a bit you will find an > illustration where a floated element overlaps two paragraphs. The caption > is "A floating image obscures borders ..." Note that the top of the > floated element is not at the top of the first paragraph. It is at the > top of the second line block. Look closely at the text, looking for the > (X). You are absolutely right about what you say. The spec does cover this (highlighted by me in the quote above) by saying that it is aligned to the top of the _current_ line box. The mistake is mine. We've been using only one and not multiple instances as you have pointed out. I've been referring to our examples only without thinking about other variables. Thank you for pointing this out. I do not profess to be an expert and expect to be corrected. I do, however, have an issue with correcting the spec since it is correct in this instance and the correction should be in my statement: 2. When floated left, it will position itself to top,left (0,0) of its "container block". which should be corrected to: 2. When floated left, it will position itself to the left of its "container block" and to the top of the current line box. In the instance where the float is presented initially, or there is only one line box, the top of the container block is the same as the top of the first line box. I hope that this is OK? I was not trying to rewrite the specs, but just trying to explain my understanding of the float. -- Gus