Re: breaking overflow

My comments below focus specifically on the use of BFCs in the context  
of float clearing.

> Tab Atkins Jr. wrote:
>> On Wed, Dec 30, 2009 at 2:14 AM, Niels Matthijs
>> <niels.matthijs@internetarchitects.be> wrote:
>>> So I was wondering whether we are trying to avoid using  
>>> overflow:hidden for
>>> unrelated effects (more control over clearing and collapsing  
>>> margins) or
>>> whether it would be good to have a break-overflow property,  
>>> allowing a
>>> certain element to break out any overflow:hidden set on its parent?
>> That's interesting, and potentially useful.  Even when I've used
>> overflow:hidden for correct reasons - I really do want the overflow  
>> to
>> be hidden - I sometimes have children that I *do* want to 'overflow'.
>> Often these children are abspos and just positioned outside of the
>> block.
>
> Note that an absolutely positioned element A is only affected
> (ie. clipped/scrolled-to) by an element O with non-'visible'  
> overflow if
> A's containing block is O ...
> I can conceive of times when you might want A to be immune to the
> overflow when O is A's containing block,

This I feel is the primary scenario where 'overflow:auto|scroll| 
hidden' fails for clearing floats. That said, I'm more than aware that  
we're currently exploiting this property just for it's side-effect.

The problem as I see it, is that all other properties - apart from the  
aforementioned 'overflow' values - that can establish BFCs,  
irrecoverably alter the box's computed width by applying the 'shrink- 
to-fit' algorithm (e.g 'display:inline-block|table-cell', absp, float,  
etc). One alternative is to generate clearing content using the :after  
pseudo element but this seems like a blatant hack, and I don't believe  
authors should have to be reliant on utilizing :after for the sole  
purpose of clearing floats. The other more conventional method is to  
place a cleared element as the last sibling of the floats, however,  
encouraging such a cross-over between HTML and CSS seems entirely  
wrong to me.

>>> From what I know, it has a nice effect on breaking collapsing  
>>> margins and clearing floats.
>>
>> Yup, though this isn't related to the overflow-ness per se; it's a
>> result of the fact that a non-auto value for overflow makes the block
>> into a BFC.
>>
>> Given that I use overflow:hidden for much more than this (float
>> management, mostly), this might also be useful for getting around
>> problems with that.  There has been discussion about a property that
>> would create BFCs directly, though, which would allow me to stop  
>> using
>> overflow to hack this.  Anyone know if there is any intention of this
>> making it into a draft soon?

I second that question.

> I raised a discussion about "neutral" BFCs in [1].  This discussion
> moved on to considering individual properties/values which might
> directly and independently give rise to the four defining properties  
> of
> BFCs (viz. preventing of margin collapsing, enclosing of dependent
> floats, providing scope for dependent clears, and not overlapping  
> other
> BFCs including floats).

The proposal that Bert points to in [1] did feature in a previous  
iteration of css3-box [2], but has been removed from the latest  
revision. Although I don't see how 'float-displace'/'indent-edge- 
reset' alone could give us the possibility of providing anything like  
a neutral BFC, since it appears to only determine line wrapping policy.

> I think it is still very much up for discussion as to which approach  
> is
> preferred.  Also, bear in mind that much of what we use BFCs for in
> real-world usage of CSS21 is hacky, as has already been mentioned.  In
> deciding the way forward in CSS3, we must remember that we are working
> in the context of superior layout/template mechanisms which may well
> make obsolete many of our current hacky desires.

I haven't checked the status of the relevant modules recently, but I'd  
assume - due to the complexity of css3-layout, for example - a  
proposed "neutral" BFC control could be adopted long before these  
modules could realistically be used by authors.

I'm certainly of the opinion that authors need the flexibility to  
explicitly create "neutral" BFCs for float clearing purposes, and look  
forward to reading some more discussion on the subject.

> [1] http://lists.w3.org/Archives/Public/www-style/2008May/0262.html

[2] http://www.w3.org/TR/2002/WD-css3-box-20021024/