Re: breaking overflow

On Dec 30, 2009, at 6:49 PM, James Hopkins wrote:

> My comments below focus specifically on the use of BFCs in the context of float clearing.
> 
> [...]
> 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).

True, for 'auto' widths. But { display:table-cell; width:100%; } might work in a lot of those situations, no? Or it would if UAs did not have the option of ignoring the effect of 'position:relative' on table-cell elements, and were required to go ahead and made them into BFCs.

> 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.

I don't think it is any worse that relying on a side effect of overflow settings. In fact, I think that creating a presentaional effect of a separate markup element without having the actual element present in the markup is a perfectly valid and important use case for ':after' (or with the ':before' example I posted earlier).

> 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.

Right. That's what ':after' is for (among other things).

Received on Thursday, 31 December 2009 04:14:53 UTC