Re: [CSS21] Proposal to define "Block container element"

On 07/21/2012 03:09 AM, Anton Prowse wrote:
>
> Proposal C:
>
> # 9.2 Controlling box generation
> #
> # The following sections describe the types of boxes that may be
> # generated in CSS 2.1. A box's type affects, in part, its behavior
> # in the visual formatting model. The 'display' property, described
> # below, specifies a box's type.
> #
> # <ins>Each _block-level element_<link to 9.2.1>, inline block,
> # inline table and table cell generates a *principal box* that
> # contains descendant boxes and generated content and is also the
> # box involved in any positioning scheme. Some block-level elements
> # may generate additional boxes in addition to the principal box:
> # 'list-item' elements. These additional boxes are placed with
> # respect to the principal box.</ins>

I think it would be better, instead of listing the types of elements,
to say something general about elements that are not 'display: none'.
Not sure how to word that nicely, though. :) But I prefer not having
lists where we're liable to leave things out, if we can avoid it. ;)

Also s/Some block-level/Some/, since this section is not specific
to block-level elements, the term doesn't clarify anything, and being
slightly vague here fits better with any plans to introduce inline
list items.

Btw, in the interests of being clear about what's changing, I suggest
your ins/del markup be wrt existing prose, and moving prose around be
annotated using some other mechanism, maybe <movefrom> and <moveto>
or an out-of-band explanation.

> # <ins>*Block container elements* are non-replaced elements whose
> # principal box is a block container box. A *block container box*
> # either contains only _block-level boxes_<link to 9.2.1> or
> # establishes an _inline formatting context_<link to 9.4.2> and thus
> # contains only _inline-level boxes_<link to 9.2.2>. The following
> # values of the 'display' property make a non-replaced element a
> # block container: 'block', 'list-item', 'table', 'inline-block',
> # 'inline-table'.</ins>

This paragraph belongs in 9.2.1, i.e. I don't think it should move.
It's very specific to blocks. I like adding the links, though.

> # 9.2.1 Block-level elements and block boxes
> #
> # *Block-level elements* are those elements of the source document
> # that are formatted visually as blocks (e.g., paragraphs). The
> # following values of the 'display' property make an element
> # block-level: 'block', 'list-item', and 'table'.
> #
> # <del>Block-level boxes 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.
> # Some block-level elements may generate additional boxes in
> # addition to the principal box: 'list-item' elements. These
> # additional boxes are placed with respect to the principal box.</del>
> #
> # <ins>The principal box of a block-level element is a block-level
> # box. *Block-level boxes* are boxes that participate in a block
> # formatting context.</ins> Except for table boxes, which are
> # described in a later chapter, and <ins>the principal box of</ins>
> # replaced elements, a block-level box is also a block container box.
> # <del>A block container box either contains only block-level boxes
> # or establishes an inline formatting context and thus contains only
> # inline-level boxes. Not all block container boxes are block-level
> # boxes: non-replaced inline blocks and non-replaced table cells are
> # block containers but not block-level boxes.</del> Block-level boxes
> # that are also block containers are called block boxes.
> #
> # <ins>Non-replaced inline blocks and non-replaced table cells are
> # block containers but are not block-level.</ins>

So rather than scrambling this section, I suggest:

  # Block-level elements are those elements of the source document
  # that are formatted visually as blocks (e.g., paragraphs). The
  # following values of the 'display' property make an element
  # block-level: 'block', 'list-item', and 'table'. <ins>Block-level
  # elements generate block-level principal boxes.</ins>
  #
  # Block-level boxes are boxes that participate in a block formatting
  # context. <movedto9.2>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. Some block-
  # level elements may generate additional boxes in addition to the
  # principal box: 'list-item' elements. These additional boxes are
  # placed with respect to the principal box.</movedto9.2>
  #
  # Except for table boxes, which are described in a later chapter,
  # and replaced elements, a block-level box is also a block container
  # box. A block container box either contains only block-level boxes
  # or establishes an inline formatting context and thus contains only
  # inline-level boxes. Not all block container boxes are block-level
  # boxes: non-replaced inline blocks and non-replaced table cells are
  # block containers but not block-level boxes. <ins>The following values
  # of the 'display' property make a non-replaced element generate a block
  # container: 'block', 'list-item', 'table', 'inline-block', 'inline-table'.
  # A non-replaced element whose principal box is a block container box is
  # a block container element.</ins>
  #
  # Block-level boxes that are also block containers are called block
  # boxes. <ins>Unless a block box `establishes a new formatting context`_,
  # its contents participate its containing block formatting context.</ins>

This minimizes the changes while keeping a coherent flow of ideas
through/between each paragraph.


The last insertion isn't necessary for this issue, but fixes a missing
idea that's already clear wrt inline boxes. Though
   "participate in its containing block formatting context"
is a little awkward, given we have the term "containing block". It's
meant to parallel the similar statement in 9.2.2. We could replace both
with
   "participate in the same XXX formatting context as the XXX box itself"
to be clearer.

~fantasai

Received on Wednesday, 25 July 2012 06:23:56 UTC