Float and Shrinkwrap
in [CSS]
|
Prev: fixed height.
Next: Newbie layout/positioning problem
From: Ben C on 9 Apr 2008 03:27 On 2008-04-08, Gus Richter <gusrichter(a)netscape.net> wrote: > dorayme wrote: >> >> I am inclined to actually use the phrase "containing block" where the >> context shows it to do a job of containing. >> >> Because the point is that it is the container, the parent, the big house >> where the children live... It is crucial that it is on the container, >> the parent, that rel pos is made for the abs to work. >> >> And I find it interesting how the "layers" work and yet the float still >> exerts the influence to push aside (displace) the text or pics in the >> following divs. Just had never thought of the float rules operating from >> a smothered "underneath" position! Those float rules are powerful voodoo >> huh? <g> > > 1. Any floated item will be out of the normal flow. > 2. When floated left, it will position itself to top,left (0,0) of its > "container block". > 3. The special feature of a float is that any inline box content in the > "container box" will shift over to make room for the float. > 4. Blah, blah, blah, blah. > > You are having difficulty in accepting the container thing, so try > asking yourself: > "If the float positions itself to 0,0 of the container block, > then what could be the container block?" Sometimes 0,0 of more than one container blocks occupy the same pixel on the screen, so this is not a good criterion. body float div In this example, 0,0 of div and body are in the same place because of margin collapsing. So which is the containing block for the float? Body, not the div, because it's the block level ancestor as specified.
From: Ben C on 9 Apr 2008 03:32 On 2008-04-09, Gus Richter <gusrichter(a)netscape.net> wrote: > Ben C wrote: >> >> Because it's positioned, and therefore in stacking level 6 rather than >> in stacking level 3. >> >> The float is always in stacking level 4. 3 is behind 4, 6 is on top of >> it. >> >> These levels are described in CSS 2.1 9.9.1. >> > Yes thank you. In the first post I mentioned the stacking order, but > never looked to see what the spec had to say. I may have got them wrong. The point is though that it comes forward because it's positioned and positioned beats floated. > My bad. Dorayme jogged my > memory by mentioning Appendix E and then it fell into place. > > I had given a quick stacking order. I note that you have given a > different one. I still have to read through them in detail. Even I have never read all of Appendix E. The section under z-index (9.9.1) is more manageable.
From: Gus Richter on 9 Apr 2008 07:51 Ben C wrote: > 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. I will have to check at a later date about z-index and overflow ... I was simply saying that "normally" we say ..... Well, here ... > [...] >> 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. Even with a background color applied to the float in order to see it, there is no stacking at all. Am I missing something? > 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: Gus Richter on 9 Apr 2008 08:08 Ben C wrote: > 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. My view/read exactly. -- Gus
From: Ben C on 9 Apr 2008 08:49
On 2008-04-09, Gus Richter <gusrichter(a)netscape.net> wrote: > Ben C wrote: [...] >> 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. > > Even with a background color applied to the float in order to see it, Yes you do need a non-transparent background on the float. > there is no stacking at all. Am I missing something? Perhaps it will help to give the <p>s also thick borders. The point is just that the float is stacked on top of the second P's background instead of going behind it. That's because floats get a higher stacking level. Consider this alternative, with no floats: div.p { background-color: red; height: 40px; margin: 10px; border: 10px solid gray; } div.notfloat { background-color: green; width: 100px; height: 300px; /* float: left */ } <div class="p"> blah blah <div class="notfloat"> not a float </div> </div> <div class="p"> blah blah blah </div> And then uncomment float: left to see the difference. |