W3C home > Mailing lists > Public > www-style@w3.org > December 2009

Re: breaking overflow

From: James Hopkins <james@idreamincode.co.uk>
Date: Thu, 31 Dec 2009 14:18:19 +0000
Cc: Anton Prowse <prowse@moonhenge.net>, www-style <www-style@w3.org>, "Tab Atkins Jr." <jackalmage@gmail.com>, Niels Matthijs <niels.matthijs@internetarchitects.be>
Message-Id: <454D65DD-5445-4748-B7FC-9C6ED8083A1C@idreamincode.co.uk>
To: Brad Kemper <brad.kemper@gmail.com>
>> 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?

It is possible to emulate the expand-to-fill behavior of a block box  
in normal flow, whilst at the same time taking into account any  
'padding' lengths, through the use of 'width:100%;box-sizing:border- 
box'. However, the main limitation here is that 'margin' lengths can't  
be applied to this particular 'display' type, although even if they  
could, any value would still be drawn outside of the specified  
'width'. In fact, we should probably shy away from using  
'display:table-*' values completely for the purposes of establishing  
BFCs, due to various property application limitations.

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

See above.

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

I'm not arguing that the generated content method is inferior; the  
'overflow' method is just as much of a hack.

Throughout the years, authors have adopted several unofficial  
techniques to clear floats. Originally, the (apparently) recommend W3C  
way was to add a clearing element (as described below), but this has  
obvious drawbacks and shouldn't be advocated. The generated content  
method - which was stumbled upon by *authors* - removed the need for a  
markup element, through the use of four extraneous properties  
('display', 'height', 'clear', and 'visibility), but this meant  
authors didn't then have the option to use this pseudo-element for  
other purposes. Creating BFCs presents the most elegant way (I  
believe) of clearing floats, however as it's already been established,  
we're having to exploit properties - that are meant for a completely  
different purpose - purely to obtain the BFC side-effect.

My point being, is that CSS has never featured an established,  
adequate mechanism for clearing floats in this manner. Up until now,  
authors have been forced to adopt a workaround borne out of findings  
from authors (generated content), or use properties for the sole  
purpose of utilizing that property's side-effect (BFC).

Creating a control that could establish a BFC and includes no other  
behavioral characteristics, is what's lacking here. Also, current  
methods are wholly unintuitive to authors learning CSS; adding a  
property named 'float-contain' (or something along those lines) would  
provide a far greater clue to authors as to exactly what that control  
does.
Received on Thursday, 31 December 2009 14:18:50 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 22 May 2012 03:47:12 GMT