Float and Shrinkwrap
in [CSS]
|
Prev: fixed height.
Next: Newbie layout/positioning problem
From: Gus Richter on 8 Apr 2008 02:09 rf wrote: > Gus Richter <gusrichter(a)netscape.net> wrote in > news:mtmdnc-aIeb5YmfanZ2dnUVZ_hadnZ2d(a)golden.net: > >> rf wrote: >>> Gus Richter <gusrichter(a)netscape.net> wrote in >>> news:WoOdnYR9Y7aBZWfanZ2dnUVZ_gKdnZ2d(a)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
From: rf on 8 Apr 2008 03:35 dorayme <doraymeRidThis(a)optusnet.com.au> wrote in news:doraymeRidThis- 10CA04.15233508042008(a)news-vip.optusnet.com.au: > In article <WoOdnYR9Y7aBZWfanZ2dnUVZ_gKdnZ2d(a)golden.net>, > 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. >> > > > 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 The containing block is not neccessarily the parent. -- Richard Killing all threads involving google groups The Usenet Improvement Project: http://improve-usenet.org
From: Ben C on 8 Apr 2008 17:37 On 2008-04-04, Gus Richter <gusrichter(a)netscape.net> wrote: > 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?_ 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. Note that "positioned" includes position: relative (see definition in 9.2.3). All that stuff in Appendix E and elsewhere about how some boxes appear to start stacking contexts to any of their descendents that don't themselves start them but not to to those that do is just a funny (though precise) way of saying that when a box is restacked it brings most of its descendents with it. It wouldn't be much good if in markup like this: <div style="float: left"> <div>hello</div> </div> the outer div was brought in front of other things but the inner one got left behind where it was. [...] If you mean "_Why_?" in the sense of why does the spec say this, my guess is that it's because position: relative boxes are containing blocks for absolutely positioned descendents: it therefore makes sense for them to be stacked in the same sort of position on the z-axis as them. Another guess at why is that when you position something and actually offset it with top/left etc. it just moves and nothing gets out of its way or flows around it in its new position. It's usually more obvious what's going on if it obscures other things on the page rather than hiding behind them. Hence the higher stacking level for all positioned boxes including relative.
From: Ben C on 8 Apr 2008 17:40 On 2008-04-04, Jeff <jeff(a)spam_me_not.com> wrote: > dorayme wrote: >> In article <MPWdnYQR98QBFWjanZ2dnUVZ_sednZ2d(a)golden.net>, >> Gus Richter <gusrichter(a)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. Yes, it's called "shrink-to-fit" and describes the width you get when you set width to auto on certain elements (tables, table cells, floats, absolutely or fixed positioned boxes). It is a technical term and is in the CSS spec. But I don't think that's what Gus meant by "shrinkwrap". I think he just meant "contains inline content that happens to flow around floats".
From: Ben C on 8 Apr 2008 17:56
On 2008-04-04, dorayme <doraymeRidThis(a)optusnet.com.au> wrote: [...] > 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). Technically it is still "in the flow" (this is the way the spec talks about it). But stacked differently, and offset if you offset it of course. Actually much of the usefulness of position: relative seems to be that you get normal flow for the 2D position but become a container for positioned descendents and can set z-index. The fact that a relatively positioned box gets the same stacking level as absolutely positioned boxes is perhaps a bit surprising but reasonable given that it is the container for them. Here is an example: <div style="float: left; height: 300px; width: 100px; background-color: green"> </div> <div style="position: relative; background-color: blue; height: 100px;"> <div style="position: absolute; top: 10px; left: 10px; background-color: red;"> foo </div> </div> It's probably more intuitive that the blue div should be on top of the green one rather than behind it since it is the containing block for the red one. Otherwise the red one would be on top of the green one but positioned relative to something behind the green one that you can't see which would be a bit weird. It is on top as a consequence of the rule that relatively positioned boxes are in stacking level 6 not 3. So hence the rule perhaps. |