Re: [CSS21] Distinguishing block boxes, block containers, and block-level elements

fantasai wrote:
> Wherein fantasai attempts to address all your comments.
> 
> CSS2.1 Issue 120
>    http://wiki.csswg.org/spec/css2.1#issue-120
> 
> *** TAKE II ***

Great progress!  I have some comments on some of the proposed edits,
below; and I'm happy with all edits not quoted here.


> Section 9.2.1 Block-level elements and block boxes
> 
>    Replace
> 
>    # Several values of the
> 
>   with
> 
>    | The following values of the

So a table caption is not a block level element.


>    Replace
> 
>    # Block-level elements (...) generate a principal block box that
>    # contains either only block boxes or only inline boxes. The
>    # principal block box establishes the containing block for descendant
>    # boxes and generated content and is also the box involved in any
>    # positioning scheme. Principal block boxes participate in a block
>    # formatting context.
> 
>    with
> 
>    | <dfn>Block-level boxes</dfn> are boxes that participate in a
>    | _block formatting context_. Each block-level element generates a
>    | principal block-level box that contains descendant boxes and
>    | generated content and is also the box involved in any positioning
>    | scheme.

OK, so tables now generate a principal block-level box.  As we discussed
in an earlier post [1], it needs to be decided whether it's the table
box or the table wrapper box.  I'm strongly in favour of the latter option.

Furthermore, I think the term "principal box" is useful in the wider
context of /all/ elements which necessarily generate a unique
"top-level" box, including not just tables but also inline tables and
inline blocks, for example.  (Talking about inline blocks in particular
is quite difficult because of the lack of a name for this box.)  I don't
necessarily envisage having a sentence listing all principal boxes;
instead, the descriptions of the values of the 'display' property could
state whether a principal box is generated.


>    and append contents of the next paragraph:
> 
>    # Some block-level elements generate additional boxes outside of the
>    # principal box: 'list-item' elements. These additional boxes are
>    # placed with respect to the principal box.
> 
>    Start a new paragraph.
> 
>    | Except for table boxes, which are described in a later chapter,
>    | and replaced elements, a block-level box is also a block container
>    | box.

Again, tables are problematic.  Is a table box (which is generated by
both a table element and an inline table element) block-level?  The
outward behaviour of table boxes is currently unspecified but is
inferred to be much like block-level behaviour in CSS21.  However, you
have previously given me the impression that they may conditionally have
different behaviour in future CSS levels.

Is the table caption box a block-level box?  It's explicitly defined to
be so in 17.4, but you've said that it may well not be in certain cases
in CSS3, and you've called it out as /not/ being so in a later edit (see
below).  Moreover, a table caption is not a block-level element.

Can there be more than on caption box per table?  Chapter 17 seems
pretty confused on the matter, although HTML401 explicitly forbids the
possibility of multiple captions.

17.4 is explicit that a table wrapper box for a (block-level) table is a
block-level box.  Your proposal makes it, in addition, a block container
box – but whether it truly is or not is going to entirely depend on the
possible nature of the caption box and table box in CSS3.  It may be
that we have to redefine it as some other kind of container box in CSS3.


>    | A <dfn>block container box</dfn> contains either only
>    | block-level boxes or only inline-level boxes.

I'm going to be daring here and suggest reformulating this as

   | A <dfn>block container box</dfn> either contains only block-level
   | boxes or establishes an inline formatting context.

This has two benefits.  Firstly, the word "contains" means two different
things in your edit (and in the current spec), namely "children" in the
case of block-level boxes, and "children of line boxes" in the case of
inline-level elements.  (That's assuming line boxes do feature in the
box containment model.)  Secondly, and perhaps more importantly, nothing
in the spec currently states which elements/boxes establish an inline
formatting context.  The sentence in question provides an ideal
opportunity to fix that.

Irrespective of this change, the dual nature of block container boxes
makes me want to name them more neutrally.  Perhaps "flow container
boxes", which sits well with "flow roots".


>    | Inline blocks,
>    | table cells, and table captions are also block container boxes,
>    | but are not block-level boxes.

The edit above makes a table caption box a block container box, which
sounds very reasonable, albeit completely unspecified in the current spec.

I got the impression from your earlier post that you don't want to
consider block-level replaced boxes as block boxes (analogously to the
inline-level situation), but that means that you'll have to not consider
them as block container boxes.  (Which seems very reasonable – although
you're planning to replace various lists of element types with "block
containers" throughout the spec, you may also need to make specific
mention of replaced boxes in those places.  In this post, I won't
comment individually on those edits about this.)

Accordingly, are replaced inline blocks, table cells and table captions
block containers?  It would be odd if they were while block-level
replaced boxes weren't.


>    | Block-level boxes that are also block containers are called
>    | <dfn>block boxes</dfn>.
>    |
[...]
> block box ( = block-level block container box or replaced
> block-level box)

See above.


> Section 9.2.1.1 Anonymous block boxes
> 
>    # In other words: if a block box (such as that generated for the DIV
>    # above) has another block box or run-in box inside it (such as the P
>    # above), then we force it to have only block boxes and run-in boxes
>    # inside it.
> 
>    s/if a block box/if a block container box/
>    s/another block box or run-in box/a block-level box/
>    s/only block boxes and run-in boxes/only block-level boxes/

The first change is fine.  The second and third are the subject of
discussion in [2].


> Section 9.2.2 Inline-level elements and inline boxes

>    Append a new paragraph:
> 
>    | An <dfn>inline box</dfn> is one that is both inline-level and whose
>    | contents participate in its containing inline formatting
>    | context. A non-replaced element with a 'display' value of 'inline'
>    | generates an inline box. An element with a 'display' value of 'run-in'
>    | can also generate an inline box; see _run-in boxes_.
>    |  Inline-level boxes that are not inline boxes (such as
>    | replaced inline elements, inline-block elements, and inline-table
>    | elements)

I know it's only a "such as", but I think it would be better to have
s/replaced inline elements/replaced inline-level elements/

>      are called <dfn>atomic inline-level boxes</dfn> because they
>    | participate in their inline formatting context as a single opaque box.


> Section 9.2.4 The 'display' property
> 
>    # inline-block
>    #   This value causes an element to generate a block box, which itself
>    #   is flowed as a single inline box, similar to a replaced element.
>    #   The inside of an inline-block is formatted as a block box, and the
>    #   element itself is formatted as an inline replaced element.
> 
>    s/generate a block...replaced element/generate an inline-level block container/
>    s/single inline/single inline-level/

I suggest also
s/as an inline replaced element/as an _atomic inline box_/

and link to the definition of atomic inline box.  The current text isn't
really correct, and moreover it seems a shame not to capitalize on our
new definition....


> Section 9.3 Positioning Schemes
> 
>    # Normal flow. In CSS 2.1, normal flow includes block formatting of
>    # block boxes, inline formatting of inline boxes, relative positioning
>    # of block or inline boxes, and positioning of run-in boxes.

Positioning of run-in boxes?  That's pretty ambiguous.  Does it mean to
say something like "treatment of run-in boxes"?


> Section 9.4.1 Block formatting contexts
> 
>    Replace
> 
>    # Floats, absolutely positioned elements, inline-blocks, table-cells,
>    # table-captions, and elements with 'overflow' other than 'visible'
> 
>    with
> 
>    | Floats, absolutely positioned elements, block containers (such as
>    | inline-blocks, table-cells, and table-captions) that are not block
>    | boxes, and block boxes with 'overflow' other than 'visible'

This assumes that floats and abspos boxes are block-level elements.
That's OK I suppose, but actually they don't participate in any block
formatting context.  Not by the implied definition of "participate"
given in the spec and in your edits, anyhow.  At least, not for abspos
boxes.  (Floats /interact/ with boxes in the same BFC, but I'm not sure
that that's the kind of participation we're talking about; certainly,
they don't obey the usual rules for laying out block-level boxes in a
BFC.  On the other hand, excluding floats really would mean changing the
definition of participation to explicitly include them again, so I'm not
saying that we necessarily want to go down this road.)


[1] http://lists.w3.org/Archives/Public/www-style/2010Aug/0125.html
[2] http://lists.w3.org/Archives/Public/www-style/2010Aug/0103.html

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

Received on Tuesday, 10 August 2010 16:12:38 UTC