Re: [CSS21] How to define "block-level box"

On 14/10/2012 12:37, Peter Moulder wrote:
> [This issue exists whether or not Anton Prowse's "block container element"
>   proposal (as currently worded) is adopted.]

> The term "block-level box" seems to be defined by this sentence in
> section 9.2.1:
>
>    # <dfn>Block-level boxes</dfn> are boxes that participate
>    # in a <a href="#block-formatting">block formatting context.</a>

> Of course www-style regulars will know that other parts of the spec
> specifically describe certain boxes being generated as block-level, but
> (a) those aren't referenced by this text that appears to be the definition,

True, but the section begins with

   # [...] The 'display' property, described below, specifies a box's
   # type.

which indicates that the reader may need to look elsewhere to find out 
when and where boxes of a given type are generated

> and (b) identifying some boxes as block-level doesn't tell us whether any
> other boxes are also block-level;

Indeed, "block-level" is simply a label.  In css3-box I'm unlikely to 
even set up the appearance of a definition, instead saying something 
like "block-level boxes <DEL>are boxes that</DEL> participate in a block 
formatting context".  That said, I'm not yet decided that the CSS21 
definition is incorrect.

> Accepting this definition, the question then becomes how to determine
> whether a given box "[participates] in a <a href="block-formatting">block
> formatting context</a>".

The intention is that everywhere that a box can arise and be block-level 
is directly stated in the spec.  In other words, it shouldn't actually 
be necessary to refer to the "definition" to deduce whether a box is 
block-level.  Rather, it's supposed to be the other way around; knowing 
that a box is block-level tells us how that box is supposed to behave: 
it participates in a BFC. (There are subtleties that I'll be trying to 
sort out in css3-box, for example: is an abspos really block-level 
and/or does it really participate in a BFC?  Such subtleties are why, at 
the moment, I don't want to rush in to fix this in CSS21.  When we know 
exactly what the future direction is, we can determine which stuff needs 
back-porting to CSS21.)

> [...] we can only assume that we should take [...] "[certain elements and
> boxes] establish new block formatting contexts for their contents" to imply
> that their contents participate in said new established block formatting
> contexts, and hence that their contents are block-level.

In theory, yes.  But, as you've noticed:

> This means that if the div below is a float/abspos/...:
>
>    <div><span>hello,</span> <span>world</span></div>
>
> then its child span elements/boxes are block-level, and hence should be
> laid out one on top of the other, contrary to the behaviour of every known
> visual UA.

which is of course problematic.  But the error here is not that 
"block-level" is incorrectly defined. Rather, it's that - according to 
the spec - some boxes establish BFCs even when they clearly don't 
because they establish inline formatting contexts instead.

By coincidence, I've been preparing a post over the last couple of days 
which addresses precisely this point.  I'll be sending it to the list 
shortly.  Basically I propose to introduce a block container box 
directly inside each BFC-establishing box.

> (a) I'm not sure that
> there's any text that explicitly says that inline-level implies not
> block-level

There isn't, although it's supposed to be implied by the fact that 
"level" is associated with participating in a particular type of 
formatting context, and a box only participates in one formatting context.

> To resolve these problems, I suggest that block formatting context should
> be defined in terms of block-level box, not the other way around.

Actually, I feel that "block-level" shouldn't be defined at all, and 
instead be merely a label.  And css3-box will also provide a much 
clearer treatment and definition of formatting contexts.  How much of 
this will be ported back to CSS21 remains to be seen.  (The only way to 
really fix CSS21 at this deep editorial level is to rewrite it entirely 
- but that's a good part of the CSS3 module effort is about.)

> I propose that "block-level box" (and "inline-level box") be defined in
> terms of the text describing the generation of that box, i.e. that it be
> the responsibility of text describing the generation of a box to specify
> whether that box is block-level or inline-level (or neither),

Precisely.  That's an important part of what the proposal for "block 
container element" mentioned above does, and it's what css3-box will do too.

> and that
> there be text in both §9.2.1 and §9.2.2 saying explicitly that if a box is
> described as block-level then it is not inline-level  (with one copy being
> reworded as "if ... inline-level then ... not block-level").  I further
> (somewhat tentatively) suggest that either section 9.2 or sections 9.2.1
> and 9.2.2 explicitly say claim that every part of CSS that specifies a box
> to be generated also specifies whether that box is block-level,
> inline-level or neither.

Yes, this is almost certainly what's needed, and is what css3-box will 
do.  In other words, I agree with the issues you're raising and, as it 
happens, they're being worked on right now.  But I don't yet have a 
feeling for the specifics of what will/should be ported back to CSS21 
though.

Cheers,
Anton Prowse
http://dev.moonhenge.net

Received on Sunday, 14 October 2012 22:25:47 UTC