Float elements break block elemens - why?
in [CSS]
|
From: Axel Dahmen on 6 Mar 2010 14:43 > But what would you suggest should be the behaviour instead? Treating all > blocks the way BFCs are treated would be undesirable for cases like a > series of paragraphs with borders containing occasional floats. Good question... I don't know. Perhaps I would expect the border of other elements to float around a floating box like their contained inline text does: ______________ | | | ___| | | | | | |___ | | | | |____________| But you're right. This doesn't sound like a good idea... I didn't think of it this way yet... Still, using "overflow:hidden" doesn't just sound right to me...
From: Ben C on 6 Mar 2010 14:46 On 2010-03-06, Axel Dahmen <KeenToKnow(a)newsgroup.nospam> wrote: > Thanks Ben, and also thanks to you, dorayme, for your example. > > I see... > > However, although this looks like a solution, I don't see/understand a > reasonable connection between a float and overflow. I can't even find > one in the specs. CSS 2.1 9.4.1: Floats, absolutely positioned elements, inline-blocks, table-cells, table-captions, and elements with 'overflow' other than 'visible' (except when that value has been propagated to the viewport) establish new block formatting contexts. [...] In a block formatting context, each box's left outer edge touches the left edge of the containing block (for right-to-left formatting, right edges touch). This is true even in the presence of floats (although a box's line boxes may shrink due to the floats), unless the box establishes a new block formatting context (in which case the box itself may become narrower [p. 137] due to the floats). > Did I just not see something appropriate? I have this feeling in my > guts that this solution is more a coincidence than intended... > > Would you mind, elaborating more on the intended connection between a > float and overflow? They don't give a reason for the connection-- i.e. for why overflow other than visible means a new BFC. But one can guess it. Suppose you had a document like this: <p> lorem ipsum... <span style="float: left; height: 400px"> ... </p> <div style="overflow: scroll"> lorem ipsum ... </div> Now suppose the float is taller than the p, so sticks out of the bottom of it. Suppose also that the div were _not_ a BFC, in other words, that there wasn't that rule about overflow: not scroll making a box into a BFC. In that case, the float would invade the div, and the text in the div would have to flow around it. Now when I scroll the div, the text in it will have to reflow around the float as it moves up and the float stays where it is. I think this is the complexity they are trying to avoid with the rule: scrolling is usually just a visual effect and doesn't result in reflowing of anything. Overflow: hidden would be less of a problem, but many browsers actually allow you to scroll overflow: hidden boxes with the DOM scrollTop etc. interfaces, and the spec doesn't say this is wrong-- scroll just means you get scrollbars. BFCs are about limiting the damage that floats can do, and the basic rule is that floats never cross the edge of a BFC.
From: Gus Richter on 6 Mar 2010 16:26 On 3/6/2010 2:43 PM, Axel Dahmen wrote: >> But what would you suggest should be the behaviour instead? Treating all >> blocks the way BFCs are treated would be undesirable for cases like a >> series of paragraphs with borders containing occasional floats. > > Good question... I don't know. Perhaps I would expect the border of > other elements to float around a floating box like their contained > inline text does: > ______________ > | | > | ___| > | | > | | > | |___ > | | > | | > |____________| > > But you're right. This doesn't sound like a good idea... I didn't think > of it this way yet... > > Still, using "overflow:hidden" doesn't just sound right to me... Then use overflow:auto; -- Gus
From: Axel Dahmen on 9 Mar 2010 18:26
Like Kyle from South Park often says: I have learned something today... Thanks a lot, Ben, for enlightening me! You've been a great help. Axel Dahmen www.axeldahmen.de ------------------------ "Ben C" <spamspam(a)spam.eggs> schrieb im Newsbeitrag news:slrnhp5c5f.4pr.spamspam(a)bowser.marioworld... > On 2010-03-06, Axel Dahmen <KeenToKnow(a)newsgroup.nospam> wrote: >> Thanks Ben, and also thanks to you, dorayme, for your example. >> >> I see... >> >> However, although this looks like a solution, I don't see/understand a >> reasonable connection between a float and overflow. I can't even find >> one in the specs. > > CSS 2.1 9.4.1: > > Floats, absolutely positioned elements, inline-blocks, table-cells, > table-captions, and elements with 'overflow' other than 'visible' > (except when that value has been propagated to the viewport) > establish new block formatting contexts. > > [...] > > In a block formatting context, each box's left outer edge touches > the left edge of the containing block (for right-to-left formatting, > right edges touch). This is true even in the presence of floats > (although a box's line boxes may shrink due to the floats), unless > the box establishes a new block formatting context (in which case > the box itself may become narrower [p. 137] due to the floats). > > >> Did I just not see something appropriate? I have this feeling in my >> guts that this solution is more a coincidence than intended... >> >> Would you mind, elaborating more on the intended connection between a >> float and overflow? > > They don't give a reason for the connection-- i.e. for why overflow > other than visible means a new BFC. But one can guess it. Suppose you > had a document like this: > > <p> > lorem ipsum... <span style="float: left; height: 400px"> ... > </p> > <div style="overflow: scroll"> > lorem ipsum ... > </div> > > Now suppose the float is taller than the p, so sticks out of the bottom > of it. Suppose also that the div were _not_ a BFC, in other words, that > there wasn't that rule about overflow: not scroll making a box into a > BFC. > > In that case, the float would invade the div, and the text in the div > would have to flow around it. Now when I scroll the div, the text in it > will have to reflow around the float as it moves up and the float stays > where it is. > > I think this is the complexity they are trying to avoid with the rule: > scrolling is usually just a visual effect and doesn't result in > reflowing of anything. > > Overflow: hidden would be less of a problem, but many browsers actually > allow you to scroll overflow: hidden boxes with the DOM scrollTop etc. > interfaces, and the spec doesn't say this is wrong-- scroll just means > you get scrollbars. > > BFCs are about limiting the damage that floats can do, and the basic > rule is that floats never cross the edge of a BFC. |