W3C home > Mailing lists > Public > www-style@w3.org > May 2012

Re: [css3-flexbox] overflow property

From: Anton Prowse <prowse@moonhenge.net>
Date: Sun, 13 May 2012 18:33:44 +0200
Message-ID: <4FAFE268.50809@moonhenge.net>
To: WWW Style <www-style@w3.org>
CC: "Kang-Hao (Kenny) Lu" <kennyluck@csail.mit.edu>, "Tab Atkins Jr." <jackalmage@gmail.com>, Morten Stenshorne <mstensho@opera.com>
On 13/05/2012 12:41, Kang-Hao (Kenny) Lu wrote:
> (12/05/13 17:44), Anton Prowse wrote:
>> 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.
> Instead of making it vague, what is the problem by saying
>    | Additionally, each of the flexbox items establishes a new block
>    | formatting context for its contents, unless it establishes a
>    | flexbox formatting context or it's a box of display 'table'
>    | (meaning that it establishes a "table formatting context").
> instead of the current wording
>    # Additionally, each of the flexbox items establishes a new
>    # formatting context for its contents.
> (By the way, typo here: s/new/new block/)

That's not a typo; that's the vagueness that I was referring to.

Although I normally err on the side of preciseness, the nice
thing about the vagueness -- which I prefer to think of as an
abstraction ;-) -- is that it allows the flexbox spec to work in
the case that other specs define other types of formatting contexts.

I.e. it's precise-vague, not sloppy-vague :-P

Note that you wouldn't need to call out tables in your proposal above, 
since a flexbox child with display:table would actually generate an 
anonymous table wrapper box which would be the flexbox item, and that 
wrapper box is a BFC.  (It's the inner table box that establishes a 
"table formatting context.)

Anton Prowse
Received on Sunday, 13 May 2012 16:34:15 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:16 UTC