Float and Shrinkwrap
in [CSS]
|
Prev: fixed height.
Next: Newbie layout/positioning problem
From: Gus Richter on 5 Apr 2008 00:49 dorayme wrote: > In article <i8GdnTQCba2JVGvanZ2dnUVZ_iydnZ2d(a)golden.net>, > Gus Richter <gusrichter(a)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
From: dorayme on 5 Apr 2008 02:23 In article <WrGdnYvHnbtPmWranZ2dnUVZ_r3inZ2d(a)golden.net>, Gus Richter <gusrichter(a)netscape.net> wrote: > dorayme wrote: > > In article <i8GdnTQCba2JVGvanZ2dnUVZ_iydnZ2d(a)golden.net>, > > Gus Richter <gusrichter(a)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. 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
From: Gus Richter on 5 Apr 2008 05:07 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
From: dorayme on 5 Apr 2008 18:09 In article <cv-dnTT7M6Kr3GranZ2dnUVZ_t2inZ2d(a)golden.net>, Gus Richter <gusrichter(a)netscape.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
From: Gus Richter on 6 Apr 2008 10:34
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 |