W3C home > Mailing lists > Public > www-style@w3.org > October 2012

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

From: Peter Moulder <peter.moulder@monash.edu>
Date: Mon, 08 Oct 2012 22:37:50 +1100
To: www-style@w3.org
Message-id: <20121008113750.GA29987@bowman.infotech.monash.edu.au>
On Thu, Sep 20, 2012 at 10:25:30AM +0200, Anton Prowse wrote:

> (and we regard the "multiple inline boxes" described by
> CSS21 as being the result of fragmentation across different line
> boxes),

Note that a similar situation occurs when a block element is split over
multiple pages.

This is something that might have been a bit clearer if we were to adopt
fantasai's earlier proposal to differentiate the term "box" into one term for
the entity before splitting and one term for a fragment (including the case
where it doesn't get split).  I can't find the thread in question, but my
memory is that others weren't convinced of the need, and objected on the
grounds that "box" is too established in use to change.  Certainly this is a
distinction that I sometimes find useful, so I was disappointed that there
wasn't much enthusiasm for it at the time.

>   : 9.2.1 Block-level elements and block boxes
>   :
>   : Block-level elements <DEL>are</DEL> <INS> – </INS> those elements of
>   : the source document that are formatted visually as blocks (e.g.,
>   : paragraphs)<DEL>.</DEL>

I've never liked the "formatted visually as blocks" description: probably
the best example of elements that are formatted visually as blocks is
'table-cell'; much more than 'list-item' or a captioned 'table' element.
It's hard to give an intuitive definition that conveys that floats are
block-level while inline-block is inline-level, and table-* (including
table-caption) are neither; but if I were to try then I'd add a paragraph
before §9.2.1 that described block-level by contrasting with inline-level
(probably by incorporating the existing introduction from §9.2.2), and
made clear that it's only an informal description (with a phrase like
"As a first approximation").  The "form new blocks of content" wording
in §9.2.2 is quite good, especially if accompanied by such a "first
approximation" qualifier.

I know it's not important.

>   : <INS> – are elements which generate a

(I think fantasai already suggested s/which/that/ here, but if that was
elsewhere then I do suggest it here too.)

>   : block-level principal box.</INS> <DEL>The following values</DEL>
>   : <INS>Values</INS> of the 'display' property <INS>that</INS> make an
>   : element block-level<DEL>:</DEL> <INS>include</INS> 'block',
>   : 'list-item', and 'table'.

Thank you for adding the word "include" there.

>   : <MovedFromBelow>*Block-level boxes* are
>   : boxes that participate in a
>   : _block formatting context_.</MovedFromBelow>

This sentence now looks like a definition, but I suspect that it's a
circular definition.  (Sorry, I haven't checked.)  I think we want
‘block-level’ (and ‘inline-level’) to be defined by the 'display' value:
we currently make clear that e.g. an element with display:block generates
a block-level box, but I'm not sure that the spec is clear about what boxes
*aren't* block-level.  One possible approach might be to be explicit that
no box is both inline-level and block-level, and that boxes with a computed
'display' of table-* (other than table-caption) are neither inline-level
nor block-level.

>   : <INS>Most block-level boxes are also block
>   : container boxes.</INS> A block container box either contains only
>   : block-level boxes or establishes an
>   : _inline formatting context_<link to 9.4.2> and thus contains only
>   : _inline-level boxes_<link to 9.2.2>.

The above text is unclear about the case of an empty box (e.g. whether a
block container box can be empty), and looks wrong for the case of
out-of-flow children: I believe that a block container box can establish an
inline formatting context and still contain out-of-flow children.  I think
there might have been some discussion about conflicting assumptions as to
whether a box does actually contain any out-of-flow would-be children, but
that the concensus was that it's best if the spec does consider them still
to be children of the would-be parent, and hence presumably that that
would-be parent does contain them.

>   : <INS>Similarly,
>   : not all block-level boxes are block container boxes: in CSS2.1,
>   : table boxes and replaced elements are can be block-level, but are
>   : not block containers.</INS>

This sentence mixes "box" and "element", and I'd be inclined to clarify the
distinction between (inner) "table box" and table elements (which generate a
block-container table wrapper box).  Addressing either one of these issues
makes the other less important to address.

>   : 17.4 Tables in the visual formatting model
>   :
>   : In terms of the visual formatting model, a table can behave
>   : like a block-level (for 'display: table') or inline-level (for
>   : 'display: inline-table') element.
>   :
>   : In both cases, the table generates a principal block
>   : <INS>container</INS> box called the table wrapper box that

Good, that change looks like it should go in regardless of the rest of the
proposal.

>   : The caption boxes are
>   : <INS>principal</INS> block-level boxes that retain their own

For me, adding that insertion in this sentence is a change for the worse.
If I correctly understand the intent, I'd prefer that this be done in a
sentence saying that elements with display:table-caption generate a principle
caption box.

(That's in any case an outstanding issue with the table stuff, from memory:
as I recall, the issue is that there's nothing that says what boxes table-*
elements generate, or how non-anonymous table-* boxes come into existence.)

This isn't a strong objection, it's just something that makes me stop to
think what it means when reading it.


No other comments.

pjrm.
Received on Monday, 8 October 2012 11:38:19 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:21:01 GMT