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

On 07/25/2010 05:46 AM, Anton Prowse wrote:
> fantasai wrote:
>> CSS2.1 Issue 120
>> http://wiki.csswg.org/spec/css2.1#issue-120
>
> 8 (Box model):[1]
>
> # The CSS box model describes the rectangular boxes that are generated
> # for elements in the document tree and laid out according to the
> # visual formatting model.
>
> Well, it describes some of them. Is it talking about the marker box of
> a list-item, though? What about various table boxes?

I believe the box model refers to CSS boxes in general, so all boxes
are part of the box model. The term "box model" isn't particularly
well-defined. But I also don't see that it needs to be -- it's only
used a couple places in introductory text.

> 9.1 (Introduction to the visual formatting model):[2]
>
> # In the visual formatting model, each element in the document tree
> # generates zero or more boxes according to the box model.
>
> "According to the box model"? The box model chapter doesn't define which
> boxes possess a box model; rather, it implicitly defers to this chapter
> and hence creates circularity. (Note that this is one of several issues
> raised by Peter Moulder in [3].)

s/according to/in/ might help here.

> 9.2 (Controlling box generation):[4]
>
> # 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.
>
> Well, they don't describe list-item marker boxes or table-* boxes.
> Indeed, although it's not really called out anywhere, an element can be
> neither block-level nor inline-level; it can be a table-*, for example.
> It would be a useful clarification of this section to call that out.

These are covered in 9.2.4, which defers to other chapters for a
fuller description of some items.

> Now to your proposal.
>
>> Section 9.2.1 Block-level elements and block boxes
>>
>> Replace
>>
>> # Block-level elements (...) generate a principal block box that
>> # contains either only block boxes or only inline boxes. The
>> # principal block box establishes the containing block for descendant
>> # boxes and generated content and is also the box involved in any
>> # positioning scheme. Principal block boxes participate in a block
>> # formatting context.
>>
>> with
>>
>> | Block-level elements generate a principal block-level box that
>> | contains descendant boxes and generated content and is also
>> | the box involved in any positioning scheme.
>
> Is this the definition of a "principal block-level box"? In particular,
> is this the only way that principal block-level boxes can arise? (See
> also [6] where I query in general whether "element" includes
> pseudo-elements and/or generated content in sentences such as these.)

Yes.

>> | A block container box contains either
>> | only block-level boxes or only inline-level boxes.
>
> Hang on, what's a "block-level box"? This is an important ambiguity. I
> /think/ you intend it to be precisely a principal block-level box or an
> anonymous block-level box as described in 9.2.1.1 (Anonymous block boxes).

Updated.

> Note that you haven't really defined "block container box", although you
> have described its behaviour. (I think perhaps these sorts of
> definition-by-behaviour-without-classification instances in the
> spec should be rewritten, since its usually unclear whether the /only/
> elements/boxes which are X are necessarily those mentioned when
> describing X's behaviour.) A block container box isn't necessarily a
> principal block-level box - nor block-level at all - for example:

>> | Boxes that are
>> | block-level block containers are called <dfn>block boxes</dfn>.
>
> OK. The term "block box" is more specialized in your proposal than in
> the current spec.

Yes, but not by much. :)

>> | Replaced block-level
>> | boxes are considered block boxes, but are not block container boxes.
>
> This directly contradicts the definition! Hence the definition needs
> rewording:

I've removed this sentence since it doesn't seem necessary and is
inconsistent with the definitions for inline-level boxes.

>> | The three terms 'block-level box', 'block container box', and
>> | 'block box' are sometimes abbreviated as 'block' where unambiguous.
>
> Indeed; although I wonder whether the abbreviation has more to do with
> the spec not bothering to nail down what is really meant than with lack
> of ambiguity. ;-)

It's mostly a cop-out to avoid rewriting too much of the spec. :)

>> 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/another block box or run-in box/a block-level box/
>> s/only block boxes and run-in boxes/only block-level boxes/
>
> Also s/if a block box/if a block container box/, no? The block
> container box for an inline-block is inline-level and yet we still
> expect it to have the above behaviour, by definition.

Yes, absolutely.

>> # When an inline box contains a block box, the inline box (and its
>> # inline ancestors within the same line box) are broken around the
>> # block. The line boxes before the break and after the break are
>> # enclosed in anonymous boxes, and the block box becomes a sibling
>> # of those anonymous boxes. When such an inline box is affected by
>> # relative positioning, the relative positioning also affects the
>> # block box.
>>
>> s/block/block-level/g
>
> Also:
>
> s/around the block/around the block-level box/
>
> (Brevity here just creates confusion.)
>
> And:
>
> s/enclosed in anonymous boxes/enclosed in anonymous block boxes/
>
> ("block boxes" is correct here because these anonymous boxes are both
> block-level and block container boxes, the former by assumption above
> and the latter by my assumption in [7].)

Right. Added.

>> Section 9.2.2 Inline-level elements and inline boxes
>>
>> # Several values of the 'display' property make an element inline:
>>
>> s/inline/inline-level/
>>
>> # 'inline', 'inline-table', 'inline-block' and 'run-in' (part of
>> # the time; see run-in boxes). Inline-level elements generate
>> # inline boxes.
>>
>> Replace "inline boxes" with "inline-level boxes, which participate
>> in an inline formatting context".
>
> Does this mean that /all/ boxes generated by an inline element are
> "inline-level"?

Yes.

> As above for "block-level box", "inline-level box" does
> not seem well defined, or rather it's defined (below) but the
> classification is vague.

Fixed.

> /How/ does an inline-level element generate inline boxes?

I don't think there's a how that needs to be specified here.

> How many of them are there? (Presumably, the minimum
> number possible whilst obeying the requirements for box generation in
> the spec, bearing in mind things like breaking across different line
> boxes and around block-level boxes.)

That's a fair description of how many. The spec isn't too clear
on this point, but I really don't feel like fixing it up. :/
Nobody's ever been confused on this point afaik.

>> Append a new paragraph:
>>
>> | An <dfn>inline box</dfn> is one that is both inline-level and whose
>> | children (if any) would participate in its containing inline formatting
>> | context. For non-replaced elements, a 'display' value of 'inline' and
>> | sometimes 'run-in' (when it is not creating a block box) generates an
>> | inline box. Inline-level boxes that are not inline boxes (such as
>> | replaced inline elements, inline-block elements, and inline-table
>> | elements) are called <dfn>atomic inline boxes</dfn> because they
>> | participate in their inline formatting context as a single opaque box.
>
> I don't understand the first sentence, largely because of the "would".
> You're trying to exclude things like inline-blocks from generating an
> inline box, so it goes hand-in-hand with the following sentences, right?

No, I'm trying to cover the case of no children. I've replaced "children"
with "contents" so I

> Does this also exclude replaced inline-level elements, or are they
> covered by the "no children" part? (The case for replaced block-level
> elements was more explicit in your changes further up.)

Replaced elements don't generate inline boxes, the generate atomic
inline-level boxes.

> I'm pretty sure by this point that your use of "inline-level box" and
> "block-level box" refers to the "outward-facing behaviour" of the boxes,
> whereas "inline box" and "block box" refers to the "inward-facing
> behaviour". For example, inline-blocks behave like inlines on the
> outside but like blocks on the inside.

Not quite. "inline-level" and "block-level" both define only outward-facing
behavior, but "inline box" and "block box" imply both inward-facing
and outward-facing behavior. They're similar in that they're both
"transparent" wrt the formatting context.

> I like your attempt to capture
> this notion, and it seems to echo various discussions on this list
> (often related to higher-level discussion about layout managers and the
> like). I think it'll turn out to be fundamentally useful for future CSS
> development to lay the groundwork here.

I agree.

> Fine. Note that the next paragraph immediately uses the terms "block
> box" and "box" interchangeably, which is valid since 9.4 states that
> block boxes participate in a block formatting context, whilst inline
> boxes participate in an inline formatting context. However, I think
> it's clearer to be more careful there. Similarly for 9.4.2.

I think it's alright.

>> Section 9.4.2 Inline formatting context
>
> <snip>
>
>> # When an inline box exceeds
>>
>> s/an inline/a non-replaced inline/
>
> See my comment above; is the generated inline-level box of a replaced
> inline-level element also an inline box?

A replaced element does not generate an inline box, it can only generate
an atomic inline-level box. So, you're right, this change isn't necessary.

~fantasai

Received on Monday, 9 August 2010 15:59:02 UTC