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

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

From: fantasai <fantasai.lists@inkedblade.net>
Date: Fri, 06 Aug 2010 18:04:26 -0700
Message-ID: <4C5CB11A.8090507@inkedblade.net>
To: Peter Moulder <peter.moulder@monash.edu>, "www-style@w3.org" <www-style@w3.org>
On 07/29/2010 12:30 AM, Peter Moulder wrote:
> Repeating what I already quickly wrote before, thank you for trying to
> fix up these notions that are such cornerstones of the CSS rendering model
> yet were previously far from clear.
>
>>    | Block-level elements generate a principal block-level box that
>
> This still has the problem that it's unclear whether it means some or all
> such elements.  Please clarify, perhaps using the word "each" or "usually".
> If the former, then make sure to be consistent with the rule that
> display:none elements generate no boxes; while if using "usually" or "some"
> or similar then it might be useful to give a link to (or follow with) a more
> precise rule for which elements do or don't.

Fixed.

> Is it true that a block-level box is one that is the principal block box of a
> block-level element?
> That's the impression given here, but the text on anonymous block boxes
> suggests that anonymous block boxes are block-level boxes, even though
> they aren't the principal block box of any element.

Fixed.

>>    | Except for ..., |  the principal block-level box is also a
>>    |<dfn>block container box</dfn>.
>
> Using<dfn>  makes this appear to be a definition of what a block container box is
> (i.e. X is a block container box if and only if it is the principal block-level box
> of some block-level element that is neither a table element nor a replaced element),
> but that turns out not to be the case.
>
> I suggest putting the definition of block container box in a single sentence,
> e.g. "A<dfn>block container box</dfn>  is a box that is either ...".

Fixed.

>>    | Boxes that are
>>    | block-level block containers are called<dfn>block boxes</dfn>.
>
> Here the use of<dfn>  suggests that this is intended to be the definition
> of the phrase "block box", whereas the wording isn't a definition:
> I'd read it as saying that all boxes that are block-level and are
> block containers are block boxes, but the wording suggests that some other
> things might be block boxes too.

I've rearranged the text a bit to be more clear. In this case, the scope
of the <dfn> is the entire paragraph.

> fantasai comments that the intent is that
>
>    block box = block-level block container box or replaced block-level box
>
> If so, then I suggest
>
>    A block box is a block-level box that is either a block container box or a
>    replaced box.
>
> Note in any case that "replaced box" needs to be defined somewhere and
> mentioned in the index.  Currently the index does have an entry for
> "replaced element", but it links to a definition that doesn't mention "box".
> I suggest that both the index entry and the definition say "element or box".

I'm just going to remove that sentence, because I'm not seeing anywhere in
the spec that needs it, and it would be clearer (and more consistent with
the inline terms) to not consider these as block boxes.

>> Section 9.2.2 Inline-level elements and inline boxes
>>
>>    # Several values of the 'display' property make an element inline[-level]:
>
> Not clear as to whether it means "sometimes" or "always".

Fixed.

> Also not clear whether any other elements can be inline-level.

CSS3 will likely define other elements as inline-level, so it should
not be worded as an exclusive list, only an exhaustive one.

>>    # Inline-level elements generate
>>    # inline[-level] boxes[, which ...].
>
> Same issues as with the corresponding block-level text.

Since inline-level elements and inline boxes have a one-to-many
relationship, I don't think those edits are appropriate here.

I will post the updated proposal in a bit.

~fantasai
Received on Monday, 9 August 2010 15:58:58 GMT

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