- From: Anton Prowse <prowse@moonhenge.net>
- Date: Sun, 13 May 2012 18:33:44 +0200
- 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.) Cheers, Anton Prowse http://dev.moonhenge.net
Received on Sunday, 13 May 2012 16:34:15 UTC