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: Tue, 17 Aug 2010 19:30:00 -0700
Message-ID: <4C6B45A8.7070600@inkedblade.net>
To: Anton Prowse <prowse@moonhenge.net>
CC: "www-style@w3.org" <www-style@w3.org>
On 08/10/2010 09:10 AM, Anton Prowse wrote:
>
> So a table caption is not a block level element.

The details of table-* formatting is left to Chapter 17. The lists
are worded to be non-exclusive, so that other chapters (and future
specifications) can specify whether other types of boxes generate
block-level boxes, inline-level boxes, block containers, or other
things defined here.

> Furthermore, I think the term "principal box" is useful in the wider
> context of /all/ elements which necessarily generate a unique
> "top-level" box, including not just tables but also inline tables and
> inline blocks, for example. (Talking about inline blocks in particular
> is quite difficult because of the lack of a name for this box.) I don't
> necessarily envisage having a sentence listing all principal boxes;
> instead, the descriptions of the values of the 'display' property could
> state whether a principal box is generated.

The "principal box" is useful for many things, but probably needs
to be defined on a per-display-type basis for things such as tables
and list items that generate multiple boxes. As of right now, I
don't think we need a more precise definition in CSS2.1, however.

> Again, tables are problematic. Is a table box (which is generated by
> both a table element and an inline table element) block-level? The
> outward behaviour of table boxes is currently unspecified but is
> inferred to be much like block-level behaviour in CSS21. However, you
> have previously given me the impression that they may conditionally have
> different behaviour in future CSS levels.
>
> Is the table caption box a block-level box? It's explicitly defined to
> be so in 17.4, but you've said that it may well not be in certain cases
> in CSS3, and you've called it out as /not/ being so in a later edit (see
> below). Moreover, a table caption is not a block-level element.

Tables should be handled in Chapter 17. Different issue, not handled
here.

> Can there be more than on caption box per table? Chapter 17 seems
> pretty confused on the matter, although HTML401 explicitly forbids the
> possibility of multiple captions.

Yes. Just because HTML forbids certain combinations of markup doesn't
mean we can't handle the equivalent combinations of CSS box generation.

>> | A <dfn>block container box</dfn> contains either only
>> | block-level boxes or only inline-level boxes.
>
> I'm going to be daring here and suggest reformulating this as
>
> | A <dfn>block container box</dfn> either contains only block-level
> | boxes or establishes an inline formatting context.

Good idea. Fixed.

>> | Inline blocks,
>> | table cells, and table captions are also block container boxes,
>> | but are not block-level boxes.
>
> The edit above makes a table caption box a block container box, which
> sounds very reasonable, albeit completely unspecified in the current spec.
>
> I got the impression from your earlier post that you don't want to
> consider block-level replaced boxes as block boxes (analogously to the
> inline-level situation) ...
> Accordingly, are replaced inline blocks, table cells and table captions
> block containers? It would be odd if they were while block-level
> replaced boxes weren't.

Fixed. No, they are not.

>> | Block-level boxes that are also block containers are called
>> | <dfn>block boxes</dfn>.
>> |
> [...]
>> block box ( = block-level block container box or replaced
>> block-level box)

Fixed.

>> Section 9.2.1.1 Anonymous block boxes
>>
>> # In other words: if a block box (such as that generated for the DIV
>> # above) has another block box or run-in box inside it (such as the P
>> # above), then we force it to have only block boxes and run-in boxes
>> # inside it.
>>
>> s/if a block box/if a block container box/
>> s/another block box or run-in box/a block-level box/
>> s/only block boxes and run-in boxes/only block-level boxes/
>
> The first change is fine. The second and third are the subject of
> discussion in [2].

I'm offline atm, so can't respond to this point.

>> Section 9.2.2 Inline-level elements and inline boxes
>
>> Append a new paragraph:
>>
>> | An <dfn>inline box</dfn> is one that is both inline-level and whose
>> | contents participate in its containing inline formatting
>> | context. A non-replaced element with a 'display' value of 'inline'
>> | generates an inline box. An element with a 'display' value of 'run-in'
>> | can also generate an inline box; see _run-in boxes_.
>> | Inline-level boxes that are not inline boxes (such as
>> | replaced inline elements, inline-block elements, and inline-table
>> | elements)
>
> I know it's only a "such as", but I think it would be better to have
> s/replaced inline elements/replaced inline-level elements/

Fixed.

>> 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/
>
> I suggest also
> s/as an inline replaced element/as an _atomic inline box_/
>
> and link to the definition of atomic inline box. The current text isn't
> really correct, and moreover it seems a shame not to capitalize on our
> new definition....

Fixed.

>> Section 9.3 Positioning Schemes
>>
>> # Normal flow. In CSS 2.1, normal flow includes block formatting of
>> # block boxes, inline formatting of inline boxes, relative positioning
>> # of block or inline boxes, and positioning of run-in boxes.
>
> Positioning of run-in boxes? That's pretty ambiguous. Does it mean to
> say something like "treatment of run-in boxes"?

Changed to "formatting of run-in boxes".

>> Section 9.4.1 Block formatting contexts
>>
>> Replace
>>
>> # Floats, absolutely positioned elements, inline-blocks, table-cells,
>> # table-captions, and elements with 'overflow' other than 'visible'
>>
>> with
>>
>> | Floats, absolutely positioned elements, block containers (such as
>> | inline-blocks, table-cells, and table-captions) that are not block
>> | boxes, and block boxes with 'overflow' other than 'visible'
>
> This assumes that floats and abspos boxes are block-level elements.
> That's OK I suppose, ...  so I'm not
> saying that we necessarily want to go down this road.)

I think this should be a separate issue, "out-of-flows are should not
be classified as block-level boxes". Because I really want to hand
this over to Bert and get an updated spec before tackling anything else.

~fantasai
Received on Wednesday, 18 August 2010 06:27:56 GMT

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