W3C home > Mailing lists > Public > www-style@w3.org > August 2010

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

From: Bert Bos <bert@w3.org>
Date: Wed, 4 Aug 2010 16:33:49 +0200
To: "www-style@w3.org" <www-style@w3.org>
Message-Id: <201008041633.50136.bert@w3.org>
On Wednesday 21 July 2010 09:16:54 fantasai wrote:
> CSS2.1 Issue 120
>    http://wiki.csswg.org/spec/css2.1#issue-120

The replacements all seem correct, except for these three:

> Section 9.2.1 Block-level elements and block boxes
>    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
>    | Block-level elements generate a principal block-level box that
>    | contains descendant boxes and generated content and is also
>    | the box involved in any positioning scheme.
>    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' elements, which are described in a later
>    | chapter, and replaced elements, the principal block-level box is
>    | also a <dfn>block container box</dfn>. A block container box
>    | contains either only block-level boxes or only inline-level
>    | boxes. Boxes that are block-level block containers are called
>    | <dfn>block boxes</dfn>. Inline blocks, table cells, and table
>    | captions are also block container boxes, but are not block-level
>    | boxes. Replaced block-level boxes are considered block boxes,
>    | but are not block container boxes.
>    |
>    | The three terms 'block-level box', 'block container box', and
>    | 'block box' are sometimes abbreviated as 'block' where
>    | unambiguous.
>    The effects of these changes are to define three terms:
>      block-level box or element
>      block container box
>      block box ( = block-level block container box or replaced
> block-level box)

The old text defined "block-level" (viz., as anything with a 'display' 
of 'block', 'list-item', 'table', or, under certain 
circumstances, 'run-in'), but the new text doesn't seem to 
define "block-level" at all.

> Section 9.2.2 Inline-level elements and inline boxes
>    # Several values of the 'display' property make an element inline:
>    s/inline/inline-level/
>    # 'inline', 'inline-table', 'inline-block' and 'run-in' (part of
>    # the time; see run-in boxes). Inline-level elements generate
>    # inline boxes.
>    Replace "inline boxes" with "inline-level boxes, which participate
>    in an inline formatting context".
>    Append a new paragraph:
>    | An <dfn>inline box</dfn> is one that is both inline-level and
>    | whose children (if any) would participate in its containing
>    | inline formatting context. For non-replaced elements, a
>    | 'display' value of 'inline' and sometimes 'run-in' (when it is
>    | not creating a block box) generates an inline box. Inline-level
>    | boxes that are not inline boxes (such as replaced inline
>    | elements, inline-block elements, and inline-table elements) are
>    | called <dfn>atomic inline boxes</dfn> because they participate
>    | in their inline formatting context as a single opaque box.
>    The effects of this change is to define three terms:
>      inline-level box or element
>      inline box or inline
>      atomic inline box
>        (we can pick a different term, this is just what I came up
> with)

"Atomic inline box" seems unnecessary.

The only place you use "atomic inline box" is in one sentence in 9.9.1 
for the 'z-index' property, and there you only *add* the term, while 
keeping the old text as well. And, in fact, that sentence in 9.9.1 was 
explicitly about inline tables and inline blocks and *not* about 
replaced elements. (You could argue that adding replaced elements to 
that sentence doesn't matter, because replaced elements don't have 
content anyway, let alone positioned content; but in a section that is 
already so difficult to understand it's better to not add more 

> Section 9.9.1 Specifying the stack level: the 'z-index' property
>    Replace
>    # The contents of inline blocks and inline tables are stacked as
>    with
>    | The contents of atomic inlines such as inline blocks and inline
>    | tables are stacked as

I think that is not an improvement, see above.

B.t.w., the latest proposed new text for this sentence under issue 60 
includes floats and certain positioned elements as well, as follows:

    Positioned elements with 'z-index: auto' (in layer 6), floats
    (layer 4), inline blocks (layer 5), and inline tables
    (layer 5), are painted as

and that copies terms from the proposed new text for the preceding list. 
E.g., item 5:

    5. the in-flow, inline-level, non-positioned descendants, including
       inline tables and inline blocks.

  Bert Bos                                ( W 3 C ) http://www.w3.org/
  http://www.w3.org/people/bos                               W3C/ERCIM
  bert@w3.org                             2004 Rt des Lucioles / BP 93
  +33 (0)4 92 38 76 92            06902 Sophia Antipolis Cedex, France
Received on Wednesday, 4 August 2010 14:34:19 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:07:48 UTC