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

On 25/07/2012 08:23, fantasai wrote:
> On 07/21/2012 03:09 AM, Anton Prowse wrote:
>>
>> Proposal C:
>>
>> # 9.2 Controlling box generation
>> #
>> # 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. The 'display' property, described
>> # below, specifies a box's type.
>> #
>> # <ins>Each _block-level element_<link to 9.2.1>, inline block,
>> # inline table and table cell generates a *principal box* that
>> # contains descendant boxes and generated content and is also the
>> # box involved in any positioning scheme. Some block-level elements
>> # may generate additional boxes in addition to the principal box:
>> # 'list-item' elements. These additional boxes are placed with
>> # respect to the principal box.</ins>
>
> I think it would be better, instead of listing the types of elements,
> to say something general about elements that are not 'display: none'.
> Not sure how to word that nicely, though. :) But I prefer not having
> lists where we're liable to leave things out, if we can avoid it. ;)

I definitely hear you, but trying to exclude element types runs the 
opposite risk, that of including things in the definition without 
intending to.  Do flex items generate a principal box?  Almost 
certainly, but for now I think the flexbox spec should say that 
explicitly.  In future, once we're more accustomed to thinking about the 
concept in other layout specs, we could consider adding a new errata to 
CSS21 which replaces an inclusion list with an exclusion list; but 
hopefully css3-box will be up to scratch by that time in any case.

If we were to provide a list of excluded types, it would include 
display:none and display:inline, but would probably exclude 
display:table-* where * != cell,caption.

> Also s/Some block-level/Some/, since this section is not specific
> to block-level elements, the term doesn't clarify anything, and being
> slightly vague here fits better with any plans to introduce inline
> list items.

Hehe, I proposed that in the past and it was rejected ;-).  Anyhow, I'm 
proposing it again as part of a solution to another bug (revolving 
around the fact that (inline-)table elements also generate an additional 
box), so hopefully it will make its way in anyway.  It's not strictly 
necessary for the current issue, though I certainly wouldn't complain if 
we made that change right here.

> Btw, in the interests of being clear about what's changing, I suggest
> your ins/del markup be wrt existing prose, and moving prose around be
> annotated using some other mechanism, maybe <movefrom> and <moveto>
> or an out-of-band explanation.

Yes, it would have been better to have done that.  The majority of 
sentences have been moved rather than changed.

>> # <ins>*Block container elements* are non-replaced elements whose
>> # principal box is a block container box. A *block container box*
>> # either contains only _block-level boxes_<link to 9.2.1> or
>> # establishes an _inline formatting context_<link to 9.4.2> and thus
>> # contains only _inline-level boxes_<link to 9.2.2>. The following
>> # values of the 'display' property make a non-replaced element a
>> # block container: 'block', 'list-item', 'table', 'inline-block',
>> # 'inline-table'.</ins>
>
> This paragraph belongs in 9.2.1, i.e. I don't think it should move.
> It's very specific to blocks. I like adding the links, though.

That's what I though, originally; hence my Proposal B which only 
factored out the principal box stuff.

But after thinking on it some more, I no longer agree.  Block containers 
are actually not at all specific to blocks.  This is because they have a 
split personality: they can either contain blocks or establish an inline 
formatting context.  Indeed, an inline-block which establishes an inline 
formatting context has nothing to do with blocks whatsoever.  (This is 
in spite of the fact that they supposedly establish a "block formatting 
context" - but the problem there is the name "BFC".  The BFC concept 
should have been divided into two distinct concepts in CSS21: flow roots 
and BFCs.  A number of places where we talk about BFCs in CSS21 
(typically where we're talking about the external impact of the box) we 
should have been talking about generic flow roots instead.  "BFC" should 
have been restricted to situations where we really are talking about the 
internal formatting of block-level descendants, which would exclude an 
inline-block with only inline-level children.)

So actually I think the introduction (9.2) is the right place for the 
paragraph, which touches upon concepts introduced in a number of other 
sections of Ch.9.

I'm out of time now, so will reply to the remainder of your post over 
the next day or two.  For the telecon, I'd like to just seek agreement 
on the idea of making such a change at all.

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

Received on Wednesday, 25 July 2012 08:13:53 UTC