Float and Shrinkwrap
in [CSS]
|
Prev: fixed height.
Next: Newbie layout/positioning problem
From: Gus Richter on 8 Apr 2008 23:00 Ben C wrote: > > Because it's positioned, and therefore in stacking level 6 rather than > in stacking level 3. > > The float is always in stacking level 4. 3 is behind 4, 6 is on top of > it. > > These levels are described in CSS 2.1 9.9.1. > Yes thank you. In the first post I mentioned the stacking order, but never looked to see what the spec had to say. My bad. Dorayme jogged my memory by mentioning Appendix E and then it fell into place. I had given a quick stacking order. I note that you have given a different one. I still have to read through them in detail. When time permits I try some of the many variables possible. Dorayme seems to be doing likewise. -- Gus
From: Gus Richter on 8 Apr 2008 23:40 Gus Richter wrote: > > When time permits I try some of the many variables possible. Dorayme > seems to be doing likewise. > I note that on alt.html dorayme is responding to a question "DIV - dynamic height" wherein she gives another variable on her referenced page: <http://netweaver.com.au/floatHouse/page10.html> That page should be included in this thread as well. The terminology of nuclear family should be removed, however, and replaced with "containg block" and "floats". IMHO of course. -- Gus
From: Ben C on 9 Apr 2008 03:12 On 2008-04-05, Gus Richter <gusrichter(a)netscape.net> wrote: > dorayme wrote: >> >> There is a fairly fairly consistent rendering of the phenomenon you have >> been wondering about, this is true. So some rules are being followed! I >> find the the talk of the various contexts, stacking etc not easy to >> negotiate - to be frank. > > The thing about stacking order for layers is that normally we say that > elements must be positioned to overlap in order for any z-index to > visually take effect. Things can overlap quite easily without being positioned, especially when overflow and overflow: visible are involved. [...] > Well, in the instance of a float we actually already have the float > layered on top of the containing block with line boxes (which we've been > calling div#shrink in our examples) and regarding this the spec ><http://www.w3.org/TR/CSS21/visuren.html#floats> has this to say: > > "The contents of floats are stacked as if floats generated new > stacking contexts, except that any elements that actually create new > stacking contexts take part in the float's parent's stacking context. > A float can overlap other boxes in the normal flow (e.g., when a > normal flow box next to a float has negative margins). When this > happens, floats are rendered in front of non-positioned in-flow > blocks, but behind in-flow inlines." The common case of a float on top a box it would be underneath (if it didn't get a higher stacking level) is this kind of thing: <p> blah blah <span style="float: left; height: 500px; width: 200px"></span> blah blah </p> <p> blah blah blah </p> The float sticks out of the bottom of the first P, but is stacked on top of the second P, even though the second P comes later in the document. Assume P has a non-transparent background in this example. I think that's the basic reason for giving floats a higher level than normal flow blocks. The inlines go on top of the float but usually they don't need to because they flow around it.
From: Ben C on 9 Apr 2008 03:18 On 2008-04-06, Gus Richter <gusrichter(a)netscape.net> wrote: > dorayme wrote: >> >> I earlier gave an indication of a test for when it has sunk in for a >> normal human. It was a predictive one, not a hindsight one. I am still >> not as optimistic as you. >> >> The slight thing that worries me in my pessimism is that many browsers >> *do* the same thing, so someone or some group who programmed the >> browsers had a certain understanding of these things. However, I can't >> even be sure of this. It may turn out that the programmers put in a set >> of rules and one of the consequences is the phenomenon you raised, but >> it takes a blind machine to bring it out (like a not particularly >> intended consequence). >> >> What would be nice is a model that tells a story that is consistent and >> meaningful and useful. That one can see in practical circumstances as >> useful. That one can understand for prediction. I am suspicious of the >> act of staring at tracts of convoluted human unfriendly systems of rules >> and saying in hindsight, ah, the penny has dropped. This seems to me to >> be a different kind of understanding than the one that can predict >> things. > > We can predict consistent behaviour as soon as we accept that: > > 1. The float's real estate covers that of the containing block, where > both start at 0,0 (without any positioning). Either may have smaller or > larger width and/or height. > 2. In the instance of a float we actually 'already' have the float > layered on top of the containing block with a pre-established stacking > order. > 3. _Without any positioning applied_ to the containing block, the float > has a higher stacking order. The float is on top. > 4. _With positioning applied_ to the containing block, the containing > block has a higher stacking order. The float is on bottom. > 5. _With positioning applied_, the stacking order may be changed by > applying z-index to the containing block. Exactly right. Not sure if it answers dorayme's question, but for that you have to ask what are the reasons for wanting to bring floats and positioned boxes forward in the stacking order, and what would happen if you didn't. The idea of the rules is for the default behaviour to give you what you want most of the time. You can always z-index if you need to do unusual things.
From: Ben C on 9 Apr 2008 03:24
On 2008-04-07, Gus Richter <gusrichter(a)netscape.net> wrote: [...] > In my examples, "wrapper" and "containing block" are two different things. > The "wrapper" is simply used to reposition the segment pairs. In your > examples in the link I mention above, you use headings to accomplish > this w/o wrappers. > The "containing block" is each one of the yellow boxes in every one of > your examples on the page linked above (yellow boxes in my examples as > well). It is a bit counter-intuitive in that normally a container comes > first in the markup, but in the case with floats, the "container block" > comes _after_ the float. No the containing block for a float is always above it in the document tree. But floats "invade" subsequent blocks in the same block formatting context. So if you do this: body float div the text in the div flows around the float. But the float's containing block is still body. This kind of situation is further complicated by the fact that the div's top margin collapses with that of body regardless of the float. body div float therefore often looks the same, although here the float's containing block is the div, not body. |