Re: [CSS21] Proposal to define "Block container element"

On 08/10/2012 13:37, Peter Moulder wrote:

> This is something that might have been a bit clearer if we were to adopt
> fantasai's earlier proposal to differentiate the term "box" into one term for
> the entity before splitting and one term for a fragment (including the case
> where it doesn't get split).  I can't find the thread in question, but my
> memory is that others weren't convinced of the need, and objected on the
> grounds that "box" is too established in use to change.  Certainly this is a
> distinction that I sometimes find useful, so I was disappointed that there
> wasn't much enthusiasm for it at the time.

I don't see a deep need for this distinction right now, but I'm open to 
the idea should a need arise.

>>    : 9.2.1 Block-level elements and block boxes
>>    :
>>    : Block-level elements <DEL>are</DEL> <INS> – </INS> those elements of
>>    : the source document that are formatted visually as blocks (e.g.,
>>    : paragraphs)<DEL>.</DEL>
>
> I've never liked the "formatted visually as blocks" description: probably
> the best example of elements that are formatted visually as blocks is
> 'table-cell'; much more than 'list-item' or a captioned 'table' element.
> It's hard to give an intuitive definition that conveys that floats are
> block-level

CSS21 says floats are block-level.  I'm on the fence about it, and will 
be considering it quite deeply for css3-box.  Personally I think of 
"block-level" as being a label rather than a defined term, but see below.

> while inline-block is inline-level, and table-* (including
> table-caption) are neither;

Table-caption is formally block-level in CSS21, though (like you, I 
suspect) I think really they're something new that happens to behave 
exactly like block-level in CSS21.  In future, there may well be 
captions which are laid out in different ways, eg at the sides of the 
table box.  Certainly, my working hypothesis is that table wrapper boxes 
establish some new type of formatting context which merely happens to 
behave exactly like a block formatting context in the ecosystem defined 
by CSS21.

> but if I were to try then I'd add a paragraph
> before §9.2.1 that described block-level by contrasting with inline-level
> (probably by incorporating the existing introduction from §9.2.2), and
> made clear that it's only an informal description (with a phrase like
> "As a first approximation").

I'll be taking care of this in css3-box.  I doubt there will be much 
appetite to make such editorial changes to CSS21.  (Every change to 
CSS21 has a /really/ high overhead, which is why it's taking so long to 
get through the errata issues btw.)

>>    : block-level principal box.</INS> <DEL>The following values</DEL>
>>    : <INS>Values</INS> of the 'display' property <INS>that</INS> make an
>>    : element block-level<DEL>:</DEL> <INS>include</INS> 'block',
>>    : 'list-item', and 'table'.
>
> Thank you for adding the word "include" there.
>
>>    : <MovedFromBelow>*Block-level boxes* are
>>    : boxes that participate in a
>>    : _block formatting context_.</MovedFromBelow>
>
> This sentence now looks like a definition, but I suspect that it's a
> circular definition.

This is older wording, not related to the proposal we're discussing.  It 
is a definition, and I hope it's not circular since my proposal is 
specifically intended to remove the circularity!  (Whether or not its a 
useful or meaningful definition is something I'm currently thinking 
about for css3-box.)

> I think we want
> ‘block-level’ (and ‘inline-level’) to be defined by the 'display' value:
> we currently make clear that e.g. an element with display:block generates
> a block-level box, but I'm not sure that the spec is clear about what boxes
> *aren't* block-level.

Well, 'display' is part of what determines the types of boxes that 
arise, and "block-level boxes" are one type of box.  Specific values of 
'display' necessarily give rise to block-level boxes, as detailed in the 
proposal.  However, that doesn't define what block-level boxes are; in 
and of itself, it merely says that there's a label called "block-level" 
and it's applied to some boxes, and in particular some values of 
'display' cause block-level boxes to be generated.

The spec intentionally doesn't say which boxes /aren't/ block-level. 
Rather, it (hopefully) says which "level" each type of generate box is, 
eg inline-level.

> One possible approach might be to be explicit that
> no box is both inline-level and block-level, and that boxes with a computed
> 'display' of table-* (other than table-caption) are neither inline-level
> nor block-level.

I agree that this is probably the missing link.  css3-box will be clear 
about that.  I'm not sure how necessary it is for CSS21 errata.  (I'm 
open to being convinced ;-).

>>    : <INS>Most block-level boxes are also block
>>    : container boxes.</INS> A block container box either contains only
>>    : block-level boxes or establishes an
>>    : _inline formatting context_<link to 9.4.2> and thus contains only
>>    : _inline-level boxes_<link to 9.2.2>.
>
> The above text is unclear about the case of an empty box (e.g. whether a
> block container box can be empty),

Hmm, I don't think it's necessary to call out that a block container box 
can be empty.  (If it is empty, I agree that it's ambiguous whether or 
not it establishes an inline formatting context, though in CSS21 I think 
it's also inconsequential.  (In css3-box it explicitly won't establish 
an inline formatting context.)

> and looks wrong for the case of
> out-of-flow children: I believe that a block container box can establish an
> inline formatting context and still contain out-of-flow children.  I think
> there might have been some discussion about conflicting assumptions as to
> whether a box does actually contain any out-of-flow would-be children, but
> that the concensus was that it's best if the spec does consider them still
> to be children of the would-be parent, and hence presumably that that
> would-be parent does contain them.

This is indeed an issue, and it's something I'm currently working on for 
css3-box.  I'm unlikely to address this directly for CSS21, but once the 
relevant bits of css3-box have been written I'll be requesting feedback 
on the issue of which bits should be ported back to CSS21.

>>    : <INS>Similarly,
>>    : not all block-level boxes are block container boxes: in CSS2.1,
>>    : table boxes and replaced elements are can be block-level, but are
>>    : not block containers.</INS>
>
> This sentence mixes "box" and "element",

Yes, the use of "element" there wasn't my personal preference.  Still, I 
don't think it's particularly confusing.  It's not wrong (in the light 
of the proposal), and gets the point across.

> and I'd be inclined to clarify the
> distinction between (inner) "table box" and table elements (which generate a
> block-container table wrapper box).

Well, it's talking about the table box as defined in the Tables chapter. 
  I don't think the current wording is ambiguous.  That chapter is clear 
about the block-level nature of the table box and the block- or 
inline-level nature of the wrapper box (in the light of the proposal).

>>    : The caption boxes are
>>    : <INS>principal</INS> block-level boxes that retain their own
>
> For me, adding that insertion in this sentence is a change for the worse.
> If I correctly understand the intent, I'd prefer that this be done in a
> sentence saying that elements with display:table-caption generate a principle
> caption box.

Yes, I would have preferred that too.  However, I didn't want to disrupt 
the existing text any further, and so I decided against that approach. 
Note that in CSS21, the box is necessary principal since there's no way 
of generating caption boxes other than via an explicit caption element. 
  In future levels, other things may be possible... and the tables spec 
will be drastically rewritten.  The Tables chapter is broken in so many 
ways that I can't say I'm particularly concerned about this specific 
issue.  The the text is not wrong, I hope.

> (That's in any case an outstanding issue with the table stuff, from memory:
> as I recall, the issue is that there's nothing that says what boxes table-*
> elements generate, or how non-anonymous table-* boxes come into existence.)

This is probably true, though I don't think I've got a record of that 
anywhere for adding to the errata list.  I'm *really* unlikely to spend 
much time on tables for CSS21 errata.  The chapter is so broken that I 
don't think it's a productive use of time.  The whole shebang needs 
rewriting in a css3 spec.

Thanks for your comments; let me know if any of rebuttals is 
unacceptable, else I don't plan to put forward any modification to the 
proposal.

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

Received on Monday, 8 October 2012 16:45:43 UTC