Float and Shrinkwrap

dorayme wrote:

In article
doraymeRidThis-A8B9E4.14270204042008...ptusnet.com.au>,
dorayme <doraymeRidThis (AT) optusnet (DOT) com.au> wrote:

In article <Gc2dnQtbW8ZTB2janZ2dnUVZ_qygnZ2d (AT) golden (DOT) net>,
Gus Richter <gusrichter (AT) netscape (DOT) 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

dorayme wrote:

In article <ocednXRAqO-WMmjanZ2dnUVZ_h6hnZ2d (AT) golden (DOT) net>,
Gus Richter <gusrichter (AT) netscape (DOT) 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

In article <ocednXRAqO-WMmjanZ2dnUVZ_h6hnZ2d (AT) golden (DOT) net>,
Gus Richter <gusrichter (AT) netscape (DOT) 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?

--
dorayme

In article <cOudnbB4fc-2KWjanZ2dnUVZ_qiinZ2d (AT) golden (DOT) net>,
Gus Richter <gusrichter (AT) netscape (DOT) net> wrote:

dorayme wrote:
In article
doraymeRidThis-A8B9E4.14270204042008...ptusnet.com.au>,
dorayme <doraymeRidThis (AT) optusnet (DOT) com.au> wrote:

In article <Gc2dnQtbW8ZTB2janZ2dnUVZ_qygnZ2d (AT) golden (DOT) net>,
Gus Richter <gusrichter (AT) netscape (DOT) 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?

Because you were hiding your gem, Gus! Under red herrings.

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.

There is no reason beyond attempted clear communication (ha!) that I put
in the transparent. Because transparent is the default. I could have
left it out. It just emphasises something essential, not a *red*
herring.

I am sorry to be hassling you so far but I hope you will come to see
that I found your q interesting and wanted to strip it down to its
essentials without the red herrings: shrink-wrapping, author widths.
Take it as a compliment that you have brought in a rough diamond and
someone wanted to polish it to show its true gleaming quality!

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.

That the text is pushed aside in all three cases (see my url above) is
what you would expect from the float rules in one specific way. But the
background phenomenum in the second case *is* rather a surprise. It's a
surprise in the following sense at least. It may be that very few people
who read CSS 2.1 would be able to *predict* the answer to the question
"What would you expect the mark up and css at the url to result in?" In
other words without knowing and talking in hindsight. This tells us at
least that it is not so clear!

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). The offsets are invisible to subsequent elements in the
sense that that they act as if the relatively positioned element is
exactly where it was had it not been so positioned. The very act of
positioning seems to be triggering the behaviour just as much as an
absolutely positioned div "following" the float, the absolute being
given a left of zero (in respect of the background). With an absolutely
positioned element, the whole show can overlay the float, text and
background.

The unfloated positioned div, of course, starts at zero left. As one
increases the value of n in "left: npx" for the positioned element (not
in the url but you can add it to see) you will see the whole unfloated
element move to the right (along with its own border and background)
exposing more and more of the float. This does rather suggest a rule is
being followed consistently.

With or without hindsight, someone might simply know. But my interest is
rather more than in the scholastic truth of what in the css 2.1 rules
backs it. Rather I think it needs explaining what practical benefits
could come of this behaviour. Specifically the background issue, not
anything else. In the end everything should resolve to a great extent at
least in practical benefit.

--
dorayme

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

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

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

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

OK, it's simply a case of "Stacking Order" after all.

Simply eh? I wish I could see it as simple.

--
dorayme

dorayme wrote:

In article <i8GdnTQCba2JVGvanZ2dnUVZ_iydnZ2d (AT) golden (DOT) net>,
Gus Richter <gusrichter (AT) netscape (DOT) 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

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

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

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.

I would be impressed if anyone who knew the specs well could predict it
though. *Pre* dict it. In the strict sense of seeing the rel pos div
following the float in the html and being asked to draw the result (yes
draw with coloured pencils) without ever having seen it in any browser.

Am not saying there are no such folk. Just that I reckon a bet would be
safe against most practising website authors.

I can scarcely believe that everyone is off talking about daylight
saving when you have raised a much more interesting matter Gus. The
subscribers of this and other newsgroups have no taste! Fancy DLS being
more interesting than stacking contexts. <g>

--
dorayme