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

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

From: Peter Moulder <peter.moulder@monash.edu>
Date: Thu, 19 Aug 2010 00:43:12 +1000
To: "www-style@w3.org" <www-style@w3.org>
Message-id: <20100818144312.GB2357@bowman.infotech.monash.edu.au>
On Tue, Aug 17, 2010 at 07:30:17PM -0700, fantasai wrote:

> Section 8.3.1 Collapsing margins
> 
>     # Two or more adjoining vertical margins of block boxes in the normal
>     # flow collapse.
> 
>     s/block boxes/block-level box/

(Of course you mean plural.)


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

That sentence has a parsing ambiguity as to whether "non-replaced" associates
just with inline blocks or with all of those things; I suggest "Inline blocks,
table cells, ... are also block container boxes (unless they are replaced
boxes)".


It surprises me that we want table captions not to be block-level boxes given
that their behaviour seems very much like a block-level box (once the anonymous
table wrapper box has been generated, at least).

Out of curiosity, what rule(s) concerning block-level boxes are we trying to
avoid here, or what's the reason for choosing for them not to be block-level ?

Note that section 17.4 currently explicitly says "caption boxes are block-level
boxes", which would conflict with this text.

If we do choose to make table-captions considered not block-level boxes, then 
we may also need to check for other conflicts.  Also, I wonder whether making
table-caption boxes non-block-level would imply normative changes to how
table-caption borders etc. are handled.


> 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/
>     s/an inline replaced element/an atomic inline-level box/

I don't see any occurrence of "single inline" after applying the first of those
substitutions, if I'm understanding it correctly.


Re "non-exlusive lists" again, I would actually tend to read

  | The following values of the 'display' property make an element block-level

as intending to mean "The following is the set of values of the 'display'
property that make an element block-level", i.e. I would take it to intend to
give a complete list.  If you want it to be taken as a non-exclusive list,
then I suggest being explicit about that.

(I agree that a literal reading doesn't make it a complete list, but given
the informal language used in most of the spec, I'd nevertheless take it as
intending to be interpreted as giving a complete list.)

pjrm.
Received on Wednesday, 18 August 2010 14:43:43 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:30 GMT