[CfC][CSS21] Errata: define "formatting context", fix related bugs (Was: Re: [css3-flexbox] overflow property)

On 14/05/2012 21:44, fantasai wrote:
> On 05/14/2012 04:31 AM, Anton Prowse wrote:
>> 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.
>>>
>>> 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.
>
> r=fantasai on all changes proposed :) Let's get these fixed.
>
> ~fantasai
>
> ====== All changes accumulated below for ease of reference ======
>
> In 11.1.1 (Overflow), replace:
>
>    | Applies to: block containers
>
> with:
>
>    | Applies to: block containers and boxes that establish a formatting
> context
>
> 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_.
>
> 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.

Also, in 10.1 (Definition of "containing block"), replace:

   # 2. For other elements, if the element's position is 'relative' or
   #    'static', the containing block is formed by the content edge of
   #    the nearest block container ancestor box.

with:

   | 2. For other elements, if the element's position is 'relative' or
   |    'static', the containing block is formed by the content edge of
   |    the nearest ancestor box that is a block container or which
   |    establishes a formatting context.


The proposal above is documented in [1] and the WG resolved to accept 
it,[2] subject to clarifying when an inline formatting context is 
established,[3] and with the proviso that the change to 11.1.1 
('overflow') may be further modified based on an assessment of whether 
that change matches reality.[3]

Specifically, the intention in CSS21 is that an inline formatting 
context (IFC) can only be established by a block container box, and the 
required clarification should make it clear that an IFC cannot be 
established by an inline non-replaced element.

CSS21 currently says:

   # 9.2.1 Block-level elements and block boxes
   #
   # [...] A block container box either contains only block-level
   # boxes or establishes an inline formatting context and thus
   # contains only inline-level boxes. [...]

   # 9.2.2 Inline-level elements and inline boxes
   #
   # [...] Inline-level elements generate inline-level boxes, which
   # are boxes that participate in an inline formatting context.
   #
   # An inline box is one that is both inline-level and whose
   # contents participate in its containing inline formatting
   # context. [...] Inline-level boxes that are not inline boxes
   # [...] are called atomic inline-level boxes because they
   # participate in their inline formatting context as a single
   # opaque box.

   # 9.4 Normal flow
   #
   # [...] Inline-level boxes participate in an inline formatting
   # context.

   # 9.4.2 Inline formatting contexts
   #
   # In an inline formatting context, boxes are laid out
   # horizontally, one after the other, beginning at the top of a
   # containing block. [...]
   #
   # [...] Thus, although line boxes in the same inline formatting
   # context generally have the same width (that of the containing
   # block), they may vary in width [...]. Line boxes in the same
   # inline formatting context generally vary in height [...].
   #
   # [...]
   #
   # Line boxes are created as needed to hold inline-level content
   # within an inline formatting context. [...]

I propose the following clarification:

Add, as the first sentence of 9.4.2 (Inline formatting contexts), the 
following sentence:

   | An inline formatting context is established by a block
   | container box that contains no block-level boxes.

(I don't believe we've ever discussed whether an empty block container 
box established an inline formatting context, but that's how I read 
9.2.1 and I don't see any harm in that interpretation.)

Please register any objections by 25 July.

[1] http://wiki.csswg.org/topics/overflow-formatting-context
[2] http://lists.w3.org/Archives/Public/www-style/2012Jun/0475.html
[3] http://lists.w3.org/Archives/Public/www-style/2012Jun/0656.html

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

Received on Sunday, 15 July 2012 08:33:50 UTC