- From: Anton Prowse <prowse@moonhenge.net>
- Date: Mon, 14 May 2012 13:31:26 +0200
- To: www-style@w3.org
- CC: fantasai <fantasai.lists@inkedblade.net>
On 13/05/2012 12:42, fantasai wrote: > On 05/11/2012 06:18 AM, 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! > > Because it isn't! You aren't formatting flexbox items as block flow. > > We could say "block containers and boxes that estabish a formatting > context", but I'm not sure how that interacts with tables. The table > box presumably establishes a table formatting context. Actually it works fine for tables, since the Applies To line for 'overflow' should have been "block containers and table boxes" anyway (see https://www.w3.org/Bugs/Public/show_bug.cgi?id=15381 ). I support your proposed wording, but I think it ought to be accompanied by a modification to 9.4 in which the term "formatting context" is introduced, and to Chapter 17, as follows. In 9.4 (Normal flow), replace: # Boxes in the normal flow belong to a formatting context, which may # be block or inline, but not both simultaneously. Block-level boxes # participate in a block formatting context. Inline-level boxes # participate in an inline formatting context. with: | Boxes in the normal flow belong to a formatting context, which in | CSS21 may be block, inline or table. In future levels of CSS, other | types of formatting context will be introduced. Block-level boxes | participate in a block formatting context. Inline-level boxes | participate in an inline formatting context. Table formatting | contexts are described in the chapter on _tables_. [Note that I omitted the bit about "not both simultaneously" because it's not actually true: <div style="overflow:hidden">text</div> The div establishes a BFC and an inline formatting context (IFC), unless we're claiming that there's an anonymous block box wrapping the text. (Although, as it happens, I would prefer it if a block container box were never allowed to establish an inline formatting context; I /would/ insist on there being anonymous block-level IFC boxes that wrap all inline-level content. That would make block container boxes truer to their name, and solve various other little mysteries in the box tree, albeit at the cost of introducing a ton of new boxes. I'd welcome comments from implementers; I think those new boxes would be purely an editorial device without needing to exist physically.] In 17.4 (Tables in the visual formatting model), replace: # [...] The table wrapper box establishes a block formatting context. # [...] with: # [...] The table wrapper box establishes a block formatting context, # and the table box establishes a table formatting context. [...] In 17.5 (Visual layout of table contents), replace: # Internal table elements generate rectangular boxes with content and # borders. Cells have padding as well. Internal table elements do not # have margins. with: # Internal table elements generate rectangular boxes which # participate in the table formatting context established by the # table box. These boxes have content and borders, and cells have # padding as well. Internal table elements do not have margins. Cheers, Anton Prowse http://dev.moonhenge.net
Received on Monday, 14 May 2012 11:32:07 UTC