Re: [css3-flexbox] overflow property

On 11/05/2012 15:18, Tab Atkins Jr. wrote:
> On Fri, May 11, 2012 at 2:58 PM, Morten Stenshorne<mstensho@opera.com>  wrote:
>> Should the 'overflow' property apply to flexboxes? Implementations do
>> support it, and I think it makes sense to do so.
>>
>> However, the flexbox spec (20120510) says that "Flexboxes are not block
>> containers", and CSS21 says that 'overflow' applies to block containers
>> only.
>>
>> BTW: When it comes to "the other non-block container thing", namely
>> tables, it looks like we have all agreed to honor overflow:hidden, while
>> overflow:scroll and overflow:auto are treated as overflow:visible...
>
> CSS21 needs fixing there.  Anton, fantasai, you led me astray!  Y'all
> told me that it doesn't make sense to call it a block context!

Indeed we did!  We said it doesn't make sense to call it a block 
formatting context, and settled on "flexbox formatting context".  (I 
guess the unnamed concept of a "table formatting context" also exists).

I think this was the right call; after all, the things it contains are 
not blocks.  The more awkward bit was the flexbox /items/ where we don't 
know if they're going to be BFCs or flexbox FCs, and so the spec is 
intentionally vague there, which again I think is also the right call.

[Note that, strictly speaking, the question of BFCs is unrelated to the 
issue of overflow, since being a BFC is not the same thing as being a 
block /container/, which is what 'overflow' requires... but it does seem 
reasonable that any element in CSS which establishes a BFC should 
generates a principal block container box, and indeed this is the case 
in CSS21.]

> Overflow should definitely apply.

Yes.

This problem exposes a fundamental issue with the relationship between 
CSS21 and successor specs: CSS21 only discusses concepts which it itself 
defines, and although we did a lot of work near the end of its cycle to 
try to abstract things a little so that they could be used more easily 
in future specs, it wasn't possible or desirable -- and met with some 
resistance -- to go too far with that.  As a result, new stuff that 
wants to use 'overflow', or indeed 'z-index' (and define its position in 
the stacking model) etc, have to opt in somehow.  There isn't much 
alternative to this, beyond ensuring that the level-n spec which 
(re-)defines 'overflow' expands the description of the box types to 
which that property applies, to cover all known types in specs which are 
current at that time.

It might be pragmatic to define flexbox containers (and flexbox items) 
to be block containers merely to opt into things like 'overflow' -- but 
I don't think it's very sound architecture.  Rather, I think you should 
add a section to css3-flexbox stating that 'overflow' applies to flexbox 
containers and flexbox items.  Other new box types in other specs might 
need to do the same.

[It's not relevant to this discussion, but I'll note anyway that the old 
wording of the "Applies To" line for 'overflow' wouldn't have helped you 
either, since that was "non-replaced block-level elements, table cells, 
inline-table, and inline-block elements", none of which fit the bill for 
flexbox items.]

Cheers,
Anton Prowse
http://dev.moonhenge.net

Received on Sunday, 13 May 2012 09:44:59 UTC