Proposal to define "Block container element"

The term "Block container element" is not defined in CSS21 (although 
block container /box/ is, in 9.2.1.).  Several participants on this list 
have expressed concern about this in the past.

In places where the context is elements (such as the "Applies to" line 
of properties) we have tended to write "block containers", deliberately 
omitting the final word so as to make the phrase suitably ambiguous to 
work around the lack of definition.

In some places we don't even make that effort: 10.8.1 refers to "block 
container elements" after the definition of the 'vertical-align' and 
'line-height' properties and even links back to 9.2.1 where of course 
there is no definition.  When asked, we've hand-waved it away as being 
merely part of the general element vs box sloppiness.

Recently I hit upon yet another place in the spec where the context is 
elements and where the spec needs to be updated to refer to block 
containers: Appendix E. [1]  The new text will be incongruous if we 
don't define "block container element".

[Furthermore, if block container element were defined, and were defined 
to include table and inline-table elements (which seems reasonable given 
that the principal table wrapper box is a block container box) then this 
spec bug -

Bug 15381 - "Applies To" line for 'overflow' property was changed to 
"block containers" which failed to account for table box 
[https://www.w3.org/Bugs/Public/show_bug.cgi?i...]

- would be fixed (because table elements would then be subject to 
'overflow', which would have its effect on the table box as per the 17.4 
property distribution between wrapper and table box)... although note 
that we've already resolved to fix this bug in a different way anyhow, 
via defining "formatting context" and setting the Applies To line to be 
"block containers and boxes that establish a formatting context" whilst 
simultaneously defining that a table box establishes a table formatting 
context.]

I have checked all instances in the spec where "block container(s)" is 
used without the word "box" in a context where one expects elements to 
be referred to, and all instances where "block container element(s)" is 
already used, and I have verified that they would remain correct if we 
were to define block container element as per my proposal below.


I propose the following insertions/deletions to 9.2.1.  The changes are 
limited to shuffling a couple of existing sentences around (untouched) 
and introducing just two new concepts:

(1) The definition of "principal block-level box" is extended to 
"principal box" for a wider range of elements (inline block, inline 
table and table cell in addition to block-level elements).  This has no 
effect on the rest of the spec, since the only cases where the principal 
box is referred to is in the context of block-level elements/boxes.

(2) The term "block container element" is introduced to mean an element 
whose principal box is a block container box, ie a block, list-item, 
inline-block, table, inline-table or table-cell in CSS21.

   # 9.2.1 Block-level elements and block boxes
   #
   # Block-level elements are those elements of the source document
   # that are formatted visually as blocks (e.g., paragraphs). The
   # following values of the 'display' property make an element
   # block-level: 'block', 'list-item', and 'table'.
   #
   # <del>Block-level boxes are boxes that participate in a block
   # formatting context.</del> Each block-level element<ins>, inline
   # block, inline table and table cell</ins> generates a principal
   # <del>block-level</del> 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>The principal box of a block-level element is a block-level
   # box. Block-level boxes are boxes that participate in a block
   # formatting context.</ins> Except for table boxes, which are
   # described in a later chapter, and <ins>the principal box of</ins>
   # replaced elements, a block-level box is also a block container box.
   # A block container box either contains only block-level boxes or
   # establishes an inline formatting context and thus contains only
   # inline-level boxes.  <del>Not all block container boxes are block-
   # level boxes: non-replaced inline blocks and non-replaced table
   # cells are block containers but not block-level boxes.</del> Block-
   # level boxes that are also block containers are called block boxes.
   #
   # <ins>Block container elements are elements whose principal box
   # is a block container box. The following values of the
   # 'display' property make an element a block container: 'block',
   # 'list-item', 'table', 'inline-block', 'inline-table'.  Non-replaced
   # inline blocks and non-replaced table cells are block containers but
   # are not block-level.
   #
   # The three terms "block-level box," "block container box," and
   # "block box" are sometimes abbreviated as "block" where unambiguous.


Any takers?

[1] http://lists.w3.org/Archives/Public/www-style... 
(first part)

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

On Sun, Jul 15, 2012, Anton Prowse wrote in one thread:

> [Despite the fact that Appendix E is written in terms of the stacking
> context and its descendants being elements not boxes, the proposal
> relies on the term "block container" which is currently a box term
> that's undefined for elements.  It would be great if we could just
> define "block container element" sensibly.]and in another thread:> Recently I hit upon yet another place in the spec where the context
> is elements and where the spec needs to be updated to refer to block
> containers: Appendix E. [1]  The new text will be incongruous if we
> don't define "block container element".The above two both contain something of an error in that although Appendix E
uses the word "element", it's explicit that it uses the word in a special sense
(see E.1, where it's defined to mean something quite a lot like "box"; and the
phrase "For each box that is a child of that element" also suggests a very
box-like understanding of what Appendix E means by "element").

Thus, it's wrong or at least misleading to describe appendix E
as being about "elements and not boxes".

Although there remain some issues as to exactly what Appendix E means by an
"element" and its descendants, I think the above shows that the existing use of
the word "element" is causing problems: in a reference document such as the CSS
2.1 spec, people expect to be able to understand the meaning of a paragraph (or
a phrase such as "If the element is a block container", in the current case)
without reading the whole chapter to see that the word "element" has a
different meaning in this appendix to the rest of the spec.

I suggest that it should at least use a different word or phrase
("render-element" ?), and wouldn't be surprised if simply "box" ended up being
the right word.

pjrm.

On 16/07/2012 07:00, Peter Moulder wrote:
> On Sun, Jul 15, 2012, Anton Prowse wrote in one thread:
>
>> [Despite the fact that Appendix E is written in terms of the stacking
>> context and its descendants being elements not boxes, the proposal
>> relies on the term "block container" which is currently a box term
>> that's undefined for elements.  It would be great if we could just
>> define "block container element" sensibly.]
>
> and in another thread:
>
>> Recently I hit upon yet another place in the spec where the context
>> is elements and where the spec needs to be updated to refer to block
>> containers: Appendix E. [1]  The new text will be incongruous if we
>> don't define "block container element".
>
> The above two both contain something of an error in that although Appendix E
> uses the word "element", it's explicit that it uses the word in a special sense
> (see E.1, where it's defined to mean something quite a lot like "box"; and the
> phrase "For each box that is a child of that element" also suggests a very
> box-like understanding of what Appendix E means by "element").
>
> Thus, it's wrong or at least misleading to describe appendix E
> as being about "elements and not boxes".D'oh!  Thanks for pointing that out.  I was aware of that in the past, 
but I certainly had forgotten that when working on Appendix E the other day.> Although there remain some issues as to exactly what Appendix E means by an
> "element" and its descendants, I think the above shows that the existing use of
> the word "element" is causing problems: in a reference document such as the CSS
> 2.1 spec, people expect to be able to understand the meaning of a paragraph (or
> a phrase such as "If the element is a block container", in the current case)
> without reading the whole chapter to see that the word "element" has a
> different meaning in this appendix to the rest of the spec.Yep, that would be nice ;-)> I suggest that it should at least use a different word or phrase
> ("render-element" ?), and wouldn't be surprised if simply "box" ended up being
> the right word.I wouldn't be surprised either!

Cheers,
Anton

On 16/07/2012 08:39, Anton Prowse wrote:
> On 16/07/2012 07:00, Peter Moulder wrote:
>> On Sun, Jul 15, 2012, Anton Prowse wrote in one thread:
>>
>>> [Despite the fact that Appendix E is written in terms of the
>>> stacking context and its descendants being elements not boxes,
>>> the proposal relies on the term "block container" which is
>>> currently a box term that's undefined for elements.  It would be
>>> great if we could just define "block container element"
>>> sensibly.]
>>
>> and in another thread:
>>
>>> Recently I hit upon yet another place in the spec where the
>>> context is elements and where the spec needs to be updated to
>>> refer to block containers: Appendix E. [1]  The new text will be
>>> incongruous if we don't define "block container element".
>>
>> The above two both contain something of an error in that although
>> Appendix E uses the word "element", it's explicit that it uses the
>> word in a special sense (see E.1, where it's defined to mean
>> something quite a lot like "box"; and the phrase "For each box that
>> is a child of that element" also suggests a very box-like
>> understanding of what Appendix E means by "element").
>>
>> Thus, it's wrong or at least misleading to describe appendix E as
>> being about "elements and not boxes".
>
> D'oh!  Thanks for pointing that out.  I was aware of that in the
> past, but I certainly had forgotten that when working on Appendix E
> the other day....although that special treatment doesn't actually help in any of the 
cases that I'm currently handling, because the only thing it does is to 
include /anonymous/ boxes under the umbrella of the word "element".  The 
boxes that I'm concerned about are never anonymous, because they are the 
principal boxes of real elements and pseudo-elements, plus the table 
boxes of table or inline-table elements (which are not anonymous despite 
not being principal).

Aside: in fact, I would argue that the marker box of a list item isn't 
anonymous either, so the example given in E.1 to illustrate the 
redefining of "element" isn't relevant.

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

On Mon, Jul 16, 2012, Anton Prowse wrote:

>D'oh!  Thanks for pointing that out.  I was aware of that in the
>past, but I certainly had forgotten that when working on Appendix E
>the other day.I'm sure; I know you've looked in detail at that appendix in the past, it's
just a matter of working without context on a little bit of that chapter.> ...although that special treatment doesn't actually help in any of
> the cases that I'm currently handling, because the only thing it
> does is to include /anonymous/ boxes under the umbrella of the word
> "element".  The boxes that I'm concerned about are never anonymous,
> ...
> Aside: in fact, I would argue that the marker box of a list item
> isn't anonymous either, so the example given in E.1 to illustrate
> the redefining of "element" isn't relevant.I agree that the first sentence of this description of ‘element’ reads like a
strict definition that excludes non-anonymous boxes.  I too would say that
marker boxes aren't anonymous (as they have an associated element: "anonymous
box" is never formally defined in CSS 2.1, but §9.2.2.1 gives what looks like
the criterion), and I too had noticed the apparent conflict between first and
third sentences (in the sense that the first sentence seems to defines
‘element’ as excluding marker boxes while the third sentence seems to make
clear that marker boxes were intended to be included as "elements").  The
aforementioned "box that is a child of that element" phrase would also be
problematic if we take that first sentence as a strict definition.  I would
tend to conclude that the first sentence isn't actually a definition after all,
and is merely trying to convey loosely what's meant.  You can also see
something of that looseness in the preceding definition of "tree order",
defined in terms of "rendering tree" even though that term isn't defined
anywhere.

If we take the E.1 definition to be informal (or in error), and take that
third sentence to imply that ‘element’ does include non-anonymous boxes,
then the special treatment does help the cases you're looking at.

(Of course that interpretation still leaves us with an error in the spec
to fix.)

pjrm.

On Tue, Jul 17, 2012 at 01:12:15AM +1000, Peter Moulder wrote:
> On Mon, Jul 16, 2012, Anton Prowse wrote:
> 
> >D'oh!  Thanks for pointing that out.  I was aware of that in the
> >past, but I certainly had forgotten that when working on Appendix E
> >the other day.
> 
> I'm sure; I know you've looked in detail at that appendix in the past, it's
> just a matter of working without context on a little bit of that chapter.Put another way: I believe no CSSWG member has written more about Appendix E
in the last five years than Anton Prowse.  If this can trip up even him,
then that's a strong argument for change even though it's just a wording change.

pjrm.

On 16/07/2012 17:12, Peter Moulder wrote:
> On Mon, Jul 16, 2012, Anton Prowse wrote:

>> ...although that special treatment doesn't actually help in any of
>> the cases that I'm currently handling, because the only thing it
>> does is to include /anonymous/ boxes under the umbrella of the word
>> "element".  The boxes that I'm concerned about are never anonymous,
>> ...
>> Aside: in fact, I would argue that the marker box of a list item
>> isn't anonymous either, so the example given in E.1 to illustrate
>> the redefining of "element" isn't relevant.
>
> I agree that the first sentence of this description of ‘element’ reads like a
> strict definition that excludes non-anonymous boxes.  I too would say that
> marker boxes aren't anonymous (as they have an associated element: "anonymous
> box" is never formally defined in CSS 2.1, but §9.2.2.1 gives what looks like
> the criterion), and I too had noticed the apparent conflict between first and
> third sentences (in the sense that the first sentence seems to defines
> ‘element’ as excluding marker boxes while the third sentence seems to make
> clear that marker boxes were intended to be included as "elements"). [...]
>
> If we take the E.1 definition to be informal (or in error), and take that
> third sentence to imply that ‘element’ does include non-anonymous boxes,
> then the special treatment does help the cases you're looking at.Given that we're not going to fix the box vs element issue in CSS21, I 
think the cleanest fix here is to explicitly call out, in the special 
definition of element in E.1, that boxes generated additionally to the 
principal box of an element count as elements too.  This would cover the 
table box of a table element, and the marker box of a list item.

I'll factor that into a revised proposal for the bug in question.

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

On 07/14/2012 07:12 PM, Anton Prowse wrote:
>
> (1) The definition of "principal block-level box" is extended to "principal box" for a wider range of elements (inline block,
> inline table and table cell in addition to block-level elements). This has no effect on the rest of the spec, since the only
> cases where the principal box is referred to is in the context of block-level elements/boxes.
>
> (2) The term "block container element" is introduced to mean an element whose principal box is a block container box, ie a
> block, list-item, inline-block, table, inline-table or table-cell in CSS21.I don't have a problem with defining these terms, however I do have
a problem with defining "principal box" generally in 9.2.1, which
is titled "Block-level elements and block boxes". If we're defining
it, it should go in 9.2.

~fantasai

On 18/07/2012 00:50, fantasai wrote:
> On 07/14/2012 07:12 PM, Anton Prowse wrote:
>>
>> (1) The definition of "principal block-level box" is extended to
>> "principal box" for a wider range of elements (inline block,
>> inline table and table cell in addition to block-level elements). This
>> has no effect on the rest of the spec, since the only
>> cases where the principal box is referred to is in the context of
>> block-level elements/boxes.
>>
>> (2) The term "block container element" is introduced to mean an
>> element whose principal box is a block container box, ie a
>> block, list-item, inline-block, table, inline-table or table-cell in
>> CSS21.
>
> I don't have a problem with defining these terms, however I do have
> a problem with defining "principal box" generally in 9.2.1, which
> is titled "Block-level elements and block boxes". If we're defining
> it, it should go in 9.2.I see your point, of course; but 9.2.1 already defines "block container 
box" which is nothing to do with block-level elements or block boxes 
either, and I was trying to disrupt the spec text at little as possible.

But here's a proposal that factors the block container stuff out into 9.2:

Proposal B:

   # 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>
   #
   # 9.2.1 Block-level elements and block boxes
   #
   # Block-level elements are those elements of the source document
   # that are formatted visually as blocks (e.g., paragraphs). The
   # following values of the 'display' property make an element
   # block-level: 'block', 'list-item', and 'table'.
   #
   # <del>Block-level boxes are boxes that participate in a block
   # formatting context. Each block-level element generates a principal
   # block-level 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.</del>
   #
   # <ins>The principal box of a block-level element is a block-level
   # box. Block-level boxes are boxes that participate in a block
   # formatting context.</ins> Except for table boxes, which are
   # described in a later chapter, and <ins>the principal box of</ins>
   # replaced elements, a block-level box is also a block container box.
   # A block container box either contains only block-level boxes or
   # establishes an inline formatting context and thus contains only
   # inline-level boxes.  <del>Not all block container boxes are block-
   # level boxes: non-replaced inline blocks and non-replaced table
   # cells are block containers but not block-level boxes.</del> Block-
   # level boxes that are also block containers are called block boxes.
   #
   # <ins>Block container elements are elements whose principal box
   # is a block container box. The following values of the
   # 'display' property make an element a block container: 'block',
   # 'list-item', 'table', 'inline-block', 'inline-table'.  Non-replaced
   # inline blocks and non-replaced table cells are block containers but
   # are not block-level.
   #
   # The three terms "block-level box," "block container box," and
   # "block box" are sometimes abbreviated as "block" where unambiguous.

Note: the only change from Proposal A is that a paragraph has moved from 
9.2.1 to 9.2.

Note: I chose to move the bit about list items and their additional box 
to 9.2.  Whilst not strictly necessary for this proposal since that 
sentence is about block-level elements, elsewhere I propose[1] to modify 
this to mention the table box of table elements  - and I wanted to 
mention the table box of inline table elements too, but since the 
sentence was talking about block-level elements I didn't.  Moving the 
bit about additional boxes to the more neutral 9.2 makes it easy to 
update that proposal to mention inline tables at that position.


[1] http://lists.w3.org/Archives/Public/www-style...

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

On 18/07/2012 09:55, Anton Prowse wrote:
> On 18/07/2012 00:50, fantasai wrote:
>> On 07/14/2012 07:12 PM, Anton Prowse wrote:
>>>
>>> (1) The definition of "principal block-level box" is extended to
>>> "principal box" for a wider range of elements (inline block,
>>> inline table and table cell in addition to block-level elements). This
>>> has no effect on the rest of the spec, since the only
>>> cases where the principal box is referred to is in the context of
>>> block-level elements/boxes.
>>>
>>> (2) The term "block container element" is introduced to mean an
>>> element whose principal box is a block container box, ie a
>>> block, list-item, inline-block, table, inline-table or table-cell in
>>> CSS21.
>>
>> I don't have a problem with defining these terms, however I do have
>> a problem with defining "principal box" generally in 9.2.1, which
>> is titled "Block-level elements and block boxes". If we're defining
>> it, it should go in 9.2.
>
> I see your point, of course; but 9.2.1 already defines "block container
> box" which is nothing to do with block-level elements or block boxes
> either, and I was trying to disrupt the spec text at little as possible.
>
> But here's a proposal that factors the block container stuff out into 9.2:
>
> Proposal B( s/block container stuff/principal box stuff/ )


And here's a proposal that factors out both the principal box stuff 
/and/ block container stuff into 9.2.

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>
   #
   # <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>
   #
   #
   # 9.2.1 Block-level elements and block boxes
   #
   # *Block-level elements* are those elements of the source document
   # that are formatted visually as blocks (e.g., paragraphs). The
   # following values of the 'display' property make an element
   # block-level: 'block', 'list-item', and 'table'.
   #
   # <del>Block-level boxes are boxes that participate in a block
   # formatting context. Each block-level element generates a principal
   # block-level 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.</del>
   #
   # <ins>The principal box of a block-level element is a block-level
   # box. *Block-level boxes* are boxes that participate in a block
   # formatting context.</ins> Except for table boxes, which are
   # described in a later chapter, and <ins>the principal box of</ins>
   # replaced elements, a block-level box is also a block container box.
   # <del>A block container box either contains only block-level boxes
   # or establishes an inline formatting context and thus contains only
   # inline-level boxes. Not all block container boxes are block-level
   # boxes: non-replaced inline blocks and non-replaced table cells are
   # block containers but not block-level boxes.</del> Block-level boxes
   # that are also block containers are called block boxes.
   #
   # <ins>Non-replaced inline blocks and non-replaced table cells are
   # block containers but are not block-level.</ins>
   #
   # The three terms "block-level box," "block container box," and
   # "block box" are sometimes abbreviated as "block" where unambiguous.

Note: the only changes from Proposals A and B are that some sentences 
have moved from 9.2.1 to 9.2 whilst the fact that block container 
elements are non-replaced has been reiterated.> Note: I chose to move the bit about list items and their additional box
> to 9.2.  Whilst not strictly necessary for this proposal since that
> sentence is about block-level elements, elsewhere I propose[1] to modify
> this to mention the table box of table elements  - and I wanted to
> mention the table box of inline table elements too, but since the
> sentence was talking about block-level elements I didn't.  Moving the
> bit about additional boxes to the more neutral 9.2 makes it easy to
> update that proposal to mention inline tables at that position.
>
>
> [1] http://lists.w3.org/Archives/Public/www-style...Cheers,
Anton Prowse
http://dev.moonhenge.net

A couple of questions:

- Is this discussion relevant to CSS 2.1 only? In other words, is a "block
container" defined in CSS3 somewhere?

- Would the proposed definition also apply to such things as <textarea>,
elements with float, and elements with absolute position?

AharonOn Sat, Jul 21, 2012 at 1:09 PM, Anton Prowse  wrote:

> On 18/07/2012 09:55, Anton Prowse wrote:
>
>> On 18/07/2012 00:50, fantasai wrote:
>>
>>> On 07/14/2012 07:12 PM, Anton Prowse wrote:
>>>
>>>>
>>>> (1) The definition of "principal block-level box" is extended to
>>>> "principal box" for a wider range of elements (inline block,
>>>> inline table and table cell in addition to block-level elements). This
>>>> has no effect on the rest of the spec, since the only
>>>> cases where the principal box is referred to is in the context of
>>>> block-level elements/boxes.
>>>>
>>>> (2) The term "block container element" is introduced to mean an
>>>> element whose principal box is a block container box, ie a
>>>> block, list-item, inline-block, table, inline-table or table-cell in
>>>> CSS21.
>>>>
>>>
>>> I don't have a problem with defining these terms, however I do have
>>> a problem with defining "principal box" generally in 9.2.1, which
>>> is titled "Block-level elements and block boxes". If we're defining
>>> it, it should go in 9.2.
>>>
>>
>> I see your point, of course; but 9.2.1 already defines "block container
>> box" which is nothing to do with block-level elements or block boxes
>> either, and I was trying to disrupt the spec text at little as possible.
>>
>> But here's a proposal that factors the block container stuff out into 9.2:
>>
>> Proposal B
>>
> ( s/block container stuff/principal box stuff/ )
>
>
> And here's a proposal that factors out both the principal box stuff /and/
> block container stuff into 9.2.
>
>
> 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>
>   #
>   # <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>
>   #
>
>   #
>   # 9.2.1 Block-level elements and block boxes
>   #
>   # *Block-level elements* are those elements of the source document
>
>   # that are formatted visually as blocks (e.g., paragraphs). The
>   # following values of the 'display' property make an element
>   # block-level: 'block', 'list-item', and 'table'.
>   #
>   # <del>Block-level boxes are boxes that participate in a block
>   # formatting context. Each block-level element generates a principal
>   # block-level 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.</del>
>   #
>   # <ins>The principal box of a block-level element is a block-level
>   # box. *Block-level boxes* are boxes that participate in a block
>
>   # formatting context.</ins> Except for table boxes, which are
>   # described in a later chapter, and <ins>the principal box of</ins>
>   # replaced elements, a block-level box is also a block container box.
>   # <del>A block container box either contains only block-level boxes
>   # or establishes an inline formatting context and thus contains only
>   # inline-level boxes. Not all block container boxes are block-level
>   # boxes: non-replaced inline blocks and non-replaced table cells are
>   # block containers but not block-level boxes.</del> Block-level boxes
>
>   # that are also block containers are called block boxes.
>   #
>   # <ins>Non-replaced inline blocks and non-replaced table cells are
>   # block containers but are not block-level.</ins>
>
>   #
>   # The three terms "block-level box," "block container box," and
>   # "block box" are sometimes abbreviated as "block" where unambiguous.
>
> Note: the only changes from Proposals A and B are that some sentences have
> moved from 9.2.1 to 9.2 whilst the fact that block container elements are
> non-replaced has been reiterated.
>
>
>  Note: I chose to move the bit about list items and their additional box
>> to 9.2.  Whilst not strictly necessary for this proposal since that
>> sentence is about block-level elements, elsewhere I propose[1] to modify
>> this to mention the table box of table elements  - and I wanted to
>> mention the table box of inline table elements too, but since the
>> sentence was talking about block-level elements I didn't.  Moving the
>> bit about additional boxes to the more neutral 9.2 makes it easy to
>> update that proposal to mention inline tables at that position.
>>
>>
>> [1] http://lists.w3.org/Archives/**Public/www-sty...<http://lists.w3.org/Archives/Public/www-style...>
>>
>
> Cheers,
> Anton Prowse
> http://dev.moonhenge.net
>
>

On 22/07/2012 10:43, Aharon (Vladimir) Lanin wrote:
>>>> On 07/14/2012 07:12 PM, Anton Prowse wrote:
>>>>>
>>>>> (1) The definition of "principal block-level box" is
>>>>> extended to "principal box" for a wider range of elements
>>>>> (inline block, inline table and table cell in addition to
>>>>> block-level elements).This
>>>>> has no effect on the rest of the spec, since the only cases
>>>>> where the principal box is referred to is in the context of
>>>>> block-level elements/boxes.
>>>>>
>>>>> (2) The term "block container element" is introduced to mean
>>>>> an element whose principal box is a block container box, ie a
>>>>> block, list-item, inline-block, table, inline-table or
>>>>> table-cell in CSS21.
>
> A couple of questions:
>
> - Is this discussion relevant to CSS 2.1 only? In other words, is a "block
> container" defined in CSS3 somewhere?"Block container box" is currently defined in css3-box but that spec 
needs a fair bit of work to get it roadworthy.  The official definition 
is in CSS21 right now.  "Block container element" will also be defined 
in css3-box, but it would be very useful to have that term in CSS21 to 
help solve several of the issues on that spec that are filed for fixing 
in errata.> - Would the proposed definition also apply to such things as <textarea>,
> elements with float, and elements with absolute position?Right now, non-replaced floated boxes and abspos boxes are classified in 
CSS21 as being block container boxes.  Floats are defined to be 
block-level boxes, but IIRC CSS21 is a little vague about whether abspos 
boxes are block-level; the implication is that they are, because the 
computed value of 'display' is set to 'block', irrespective of the 
specified value.  Hence floats and abspos boxes are principal 
(block-level) boxes according to the current spec, and will continue to 
be under my proposed change.  Hence non-replaced floats and abspos 
elements will indeed be block container elements.

<textarea> is harder to speak for, since HTML form elements are magic 
and CSS doesn't entirely define their behaviour.  I think of form 
elements as being replaced elements.  Whether that's the case or not, 
<textarea> (along with <input>, <select> and <button>) are recommended 
in Appendix D to be inline-blocks.  This means that:
(1) the atomic box that these four elements (and indeed inline blocks in 
general) generate will be a "principal box" under my proposed change.
(2) the question of whether they will be block container elements 
depends on whether their principal box is a block container box.  If you 
believe, like I do, that they are replaced elements, then their 
principal box is /not/ a block container box.  If they are not replaced 
elements, then implementations each need to decide upon an answer.

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

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. ;)

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.

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.> # <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.> # 9.2.1 Block-level elements and block boxes
> #
> # *Block-level elements* are those elements of the source document
> # that are formatted visually as blocks (e.g., paragraphs). The
> # following values of the 'display' property make an element
> # block-level: 'block', 'list-item', and 'table'.
> #
> # <del>Block-level boxes are boxes that participate in a block
> # formatting context. Each block-level element generates a principal
> # block-level 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.</del>
> #
> # <ins>The principal box of a block-level element is a block-level
> # box. *Block-level boxes* are boxes that participate in a block
> # formatting context.</ins> Except for table boxes, which are
> # described in a later chapter, and <ins>the principal box of</ins>
> # replaced elements, a block-level box is also a block container box.
> # <del>A block container box either contains only block-level boxes
> # or establishes an inline formatting context and thus contains only
> # inline-level boxes. Not all block container boxes are block-level
> # boxes: non-replaced inline blocks and non-replaced table cells are
> # block containers but not block-level boxes.</del> Block-level boxes
> # that are also block containers are called block boxes.
> #
> # <ins>Non-replaced inline blocks and non-replaced table cells are
> # block containers but are not block-level.</ins>So rather than scrambling this section, I suggest:

  # Block-level elements are those elements of the source document
  # that are formatted visually as blocks (e.g., paragraphs). The
  # following values of the 'display' property make an element
  # block-level: 'block', 'list-item', and 'table'. <ins>Block-level
  # elements generate block-level principal boxes.</ins>
  #
  # Block-level boxes are boxes that participate in a block formatting
  # context. <movedto9.2>Each block-level element generates a principal
  # block-level 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.</movedto9.2>
  #
  # Except for table boxes, which are described in a later chapter,
  # and replaced elements, a block-level box is also a block container
  # box. A block container box either contains only block-level boxes
  # or establishes an inline formatting context and thus contains only
  # inline-level boxes. Not all block container boxes are block-level
  # boxes: non-replaced inline blocks and non-replaced table cells are
  # block containers but not block-level boxes. <ins>The following values
  # of the 'display' property make a non-replaced element generate a block
  # container: 'block', 'list-item', 'table', 'inline-block', 'inline-table'.
  # A non-replaced element whose principal box is a block container box is
  # a block container element.</ins>
  #
  # Block-level boxes that are also block containers are called block
  # boxes. <ins>Unless a block box `establishes a new formatting context`_,
  # its contents participate its containing block formatting context.</ins>

This minimizes the changes while keeping a coherent flow of ideas
through/between each paragraph.


The last insertion isn't necessary for this issue, but fixes a missing
idea that's already clear wrt inline boxes. Though
   "participate in its containing block formatting context"
is a little awkward, given we have the term "containing block". It's
meant to parallel the similar statement in 9.2.2. We could replace both
with
   "participate in the same XXX formatting context as the XXX box itself"
to be clearer.

~fantasai

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

Continuing my response[1] to fantasai's post...On 25/07/2012 08:23, fantasai wrote:
> On 07/21/2012 03:09 AM, Anton Prowse wrote:
>> # 9.2.1 Block-level elements and block boxes
>> #
>> # *Block-level elements* are those elements of the source document
>> # that are formatted visually as blocks (e.g., paragraphs). The
>> # following values of the 'display' property make an element
>> # block-level: 'block', 'list-item', and 'table'.
>> #
>> # <del>Block-level boxes are boxes that participate in a block
>> # formatting context. Each block-level element generates a principal
>> # block-level 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.</del>
>> #
>> # <ins>The principal box of a block-level element is a block-level
>> # box. *Block-level boxes* are boxes that participate in a block
>> # formatting context.</ins> Except for table boxes, which are
>> # described in a later chapter, and <ins>the principal box of</ins>
>> # replaced elements, a block-level box is also a block container box.
>> # <del>A block container box either contains only block-level boxes
>> # or establishes an inline formatting context and thus contains only
>> # inline-level boxes. Not all block container boxes are block-level
>> # boxes: non-replaced inline blocks and non-replaced table cells are
>> # block containers but not block-level boxes.</del> Block-level boxes
>> # that are also block containers are called block boxes.
>> #
>> # <ins>Non-replaced inline blocks and non-replaced table cells are
>> # block containers but are not block-level.</ins>
>
> So rather than scrambling this section, I suggest:
>
>   # Block-level elements are those elements of the source document
>   # that are formatted visually as blocks (e.g., paragraphs). The
>   # following values of the 'display' property make an element
>   # block-level: 'block', 'list-item', and 'table'. <ins>Block-level
>   # elements generate block-level principal boxes.</ins>
>   #
>   # Block-level boxes are boxes that participate in a block formatting
>   # context. <movedto9.2>Each block-level element generates a principal
>   # block-level 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.</movedto9.2>
>   #
>   # Except for table boxes, which are described in a later chapter,
>   # and replaced elements, a block-level box is also a block container
>   # box. A block container box either contains only block-level boxes
>   # or establishes an inline formatting context and thus contains only
>   # inline-level boxes. Not all block container boxes are block-level
>   # boxes: non-replaced inline blocks and non-replaced table cells are
>   # block containers but not block-level boxes. <ins>The following values
>   # of the 'display' property make a non-replaced element generate a block
>   # container: 'block', 'list-item', 'table', 'inline-block', 'inline-table'.
>   # A non-replaced element whose principal box is a block container box is
>   # a block container element.</ins>
>   #
>   # Block-level boxes that are also block containers are called block
>   # boxes. <ins>Unless a block box `establishes a new formatting context`_,
>   # its contents participate its containing block formatting context.</ins>
>
> This minimizes the changes while keeping a coherent flow of ideas
> through/between each paragraph.This is very similar to my Proposal B in [2].

I think the key thing we need to decide upon is whether block container 
boxes should be discussed in 9.2 or in 9.2.1.  (As I argued in [1], I 
prefer it to happen in 9.2, since block container boxes may be 
block-level, inline-level, flex-level....)  Let's deal with the other 
details afterwards.> The last insertion isn't necessary for this issue, but fixes a missing
> idea that's already clear wrt inline boxes. Though
>    "participate in its containing block formatting context"
> is a little awkward, given we have the term "containing block". It's
> meant to parallel the similar statement in 9.2.2. We could replace both
> with
>    "participate in the same XXX formatting context as the XXX box itself"
> to be clearer.I support the idea, but I'm not sure that the proposed change is totally 
correct.  Let's treat this as a separate topic.


[1] http://lists.w3.org/Archives/Public/www-style...
[2] http://lists.w3.org/Archives/Public/www-style...

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

On 04/08/2012 12:45, Anton Prowse wrote:
> On 25/07/2012 08:23, fantasai wrote:
>> This minimizes the changes while keeping a coherent flow of ideas
>> through/between each paragraph.
>
> This is very similar to my Proposal B in [2].We're iterating towards something mutually agreeable. Here's a proposal 
which incorporates the majority of each of our preferences.


(1) The definition of "principal block-level box" is extended to
"principal box" for a wider range of elements (in CSS21: inline block,
inline table and table cell in addition to block-level elements). This
has no effect on the rest of the spec, since the only cases where the 
principal box is referred to is in the context of block-level 
elements/boxes.  The definition is moved to 9.2 since it is no longer 
specific to block-level elements.

(2) The term "block container element" is introduced to mean an
element whose principal box is a block container box (in CSS21:
block, inline-block, list-item, table, inline-table, table-caption, 
table-cell).

(3) Technical terms used are linked to their definitions further down 
the chapter.

(4) The term "block-level element", which is currently only fuzzily 
defined, is formally defined in 9.2.1 to mean an element whose principal 
box is block-level.  The incomplete list of 'display' values which make 
an element block-level is explicitly called out as non-exhaustive.

(5) The discussion of the relationship between block container boxes and 
block-level boxes is qualified as being specific to CSS21, thus making 
this section forwards-compatible with future levels.

(6) The description of the values of the 'display' property in 9.2.4 are 
made more careful, ensuring that generated boxes are explicitly stated 
to be principal boxes where necessary (thus ensuring that the spec is 
clear about which elements are block-level and/or block containers).  An 
existing sentence is parenthesized in the 'inline-block' value 
description, since it is both slightly woolly and redundant.

(7) A couple of tweaks are made to 17.4 (Tables in the visual formatting 
model) to ensure that the descriptions used tie in correctly with the 
other changes, eg as per (6) above.


Proposal E:

   : 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.
   :
   : <MovedFrom9.2.1><DEL>Each block-level element generates</DEL>
   : <INS>Certain values of the 'display' property cause an element of
   : the source document to generate</INS> a
   : *principal <DEL>block-level</DEL> box* that contains descendant
   : boxes and generated content and is also the box involved in any
   : positioning scheme. Some <DEL>block-level</DEL> 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.</MovedFrom9.2.1>
   :
   : 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> <INS> – are elements which generate a
   : 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'. <MovedFromBelow>*Block-level boxes* are
   : boxes that participate in a
   : _block formatting context_.</MovedFromBelow>
   :
   : <MovedToAbove>Block-level boxes are boxes that participate in a
   : block formatting context.</MovedToAbove> <MovedTo9.2>Each
   : block-level element generates a principal block-level 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.</MovedTo9.2>
   :
   : <DEL>Except for table boxes, which are described in a later
   : chapter, and replaced elements</DEL><INS>In CSS 2.1</INS>, a
   : block-level box is also a block container box <INS>unless it is
   : a table box or the principal box of a replaced element</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>. <INS>An element
   : whose principal box is a block container box is a *block container
   : element*. Values of the 'display' property which make a
   : non-replaced element generate a block container include 'block',
   : 'list-item' and 'inline-block'.</INS> Not all block container boxes
   : are block-level boxes: non-replaced inline blocks and non-replaced
   : table cells are block containers but <INS>are</INS> not block-level
   : <DEL>boxes</DEL>. Block-level boxes that are also block containers
   : are called block boxes.
   :
   : The three terms "block-level box," "block container box," and
   : "block box" are sometimes abbreviated as "block" where unambiguous.


   : 9.2.4 The 'display' property
   :
   : [...]
   :
   : The values of this property have the following meanings:
   :
   : block
   :   This value causes an element to generate a <INS>principal</INS>
   :   block box.
   :
   : inline-block
   :   This value causes an element to generate <DEL>an</DEL>
   :   <INS>a principal</INS> inline-level block container.
   :   <INS>(</INS>The inside of an inline-block is formatted as a block
   :   box, and the element itself is formatted as an atomic
   :   inline-level box.<INS>)</INS>
   :
   : inline
   :   This value causes an element to generate one or more inline
   :   boxes.
   :
   : list-item
   :   This value causes an element (e.g., LI in HTML) to generate a
   :   principal block box and a marker box. [...]
   :
   : none
   :   [...]
   :
   : table, inline-table, table-row-group, table-column,
   : table-column-group, table-header-group, table-footer-group,
   : table-row, table-cell, and table-caption
   :   [...]


   : 17.4 Tables in the visual formatting model
   :
   : In terms of the visual formatting model, a table can behave
   : like a block-level (for 'display: table') or inline-level (for
   : 'display: inline-table') element.
   :
   : In both cases, the table generates a principal block
   : <INS>container</INS> box called the table wrapper box that
   : contains the table box itself and any caption boxes (in
   : document order). The table box is a block-level box that contains
   : the table's internal table boxes. The caption boxes are
   : <INS>principal</INS> block-level boxes that retain their own
   : content, padding, margin, and border areas, and are rendered as
   : normal block boxes inside the table wrapper box. Whether the
   : caption boxes are placed before or after the table box is decided
   : by the 'caption-side' property, as described below.
   :
   : The table wrapper box is <DEL>a 'block' box if the table is
   : block-level</DEL> <INS>block-level for 'display: table'</INS>, and
   : <DEL>an 'inline-block' box if the table is inline-level</DEL>
   : <INS>inline-level for 'display: inline-table'</INS>. [...]


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

On 09/03/2012 01:56 PM, Anton Prowse wrote:
>
> : <INS>Certain values of the 'display' property cause an element of
> : the source document to generate</INS> a
> : *principal <DEL>block-level</DEL> box*I still find this phrase awkward, because it's so vague. Since you don't
want to list 'display: none' explicitly, how about:

   <INS>Elements that appear in the formatting structure generate</INS>> : <DEL>Except for table boxes, which are described in a later
> : chapter, and replaced elements</DEL><INS>In CSS 2.1</INS>, a
> : block-level box is also a block container box <INS>unless it is
> : a table box or the principal box of a replaced element</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>. <INS>An element
> : whose principal box is a block container box is a *block container
> : element*. Values of the 'display' property which make a
> : non-replaced element generate a block container include 'block',
> : 'list-item' and 'inline-block'.</INS> Not all block container boxes
> : are block-level boxes: non-replaced inline blocks and non-replaced
> : table cells are block containers but <INS>are</INS> not block-level
> : <DEL>boxes</DEL>. Block-level boxes that are also block containers
> : are called block boxes.I might consider

   | Most block-level boxes are also block container boxes.
   | A block container box [... stuff from above ...] 'inline-block'.
   | Not all block container boxes [... stuff from above ...] block-level.
   | 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.
   | Block-level boxes that are also block containers are called block boxes.

You do need an s/which make/that make/, though.

Otherwise, the changes all look good to me.

~fantasai

On 19/09/2012 17:37, fantasai wrote:
> On 09/03/2012 01:56 PM, Anton Prowse wrote:
>>
>> : <INS>Certain values of the 'display' property cause an element of
>> : the source document to generate</INS> a
>> : *principal <DEL>block-level</DEL> box*
>
> I still find this phrase awkward, because it's so vague. Since you don't
> want to list 'display: none' explicitly, how about:
>
>    <INS>Elements that appear in the formatting structure generate</INS>To summarize what we discussed on the telecon[1] for the record, my 
concern is whether we want inline elements to generate a principal box. 
  Like you, I think the box model is more natural and coherent if they 
do (and we regard the "multiple inline boxes" described by CSS21 as 
being the result of fragmentation across different line boxes), but I'm 
concerned that this might conflict with certain other aspects of the 
inline formatting model described in CSS21.  If so, it may well be that 
we can change those aspects since I suspect that either they don't 
actually impact the rendering result or else they already create 
inconsistencies.  But I'd prefer to defer that investigation to later.

So in [1] the WG resolved to keep my vague wording, on the understanding 
that the issue of whether an inline element generates a principal box be 
treated as a separate issue that will progress in parallel with this 
one. That issue is duly filed at [2].>> : <DEL>Except for table boxes, which are described in a later
>> : chapter, and replaced elements</DEL><INS>In CSS 2.1</INS>, a
>> : block-level box is also a block container box <INS>unless it is
>> : a table box or the principal box of a replaced element</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>. <INS>An element
>> : whose principal box is a block container box is a *block container
>> : element*. Values of the 'display' property which make a
>> : non-replaced element generate a block container include 'block',
>> : 'list-item' and 'inline-block'.</INS> Not all block container boxes
>> : are block-level boxes: non-replaced inline blocks and non-replaced
>> : table cells are block containers but <INS>are</INS> not block-level
>> : <DEL>boxes</DEL>. Block-level boxes that are also block containers
>> : are called block boxes.
>
> I might consider
>
>    | Most block-level boxes are also block container boxes.
>    | A block container box [... stuff from above ...] 'inline-block'.
>    | Not all block container boxes [... stuff from above ...] block-level.
>    | 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.
>    | Block-level boxes that are also block containers are called block
> boxes.
>
> You do need an s/which make/that make/, though.I'm happy with this suggestion, and in [1] we resolved to accept my 
proposal as modified by this suggestion.  Specifically, the resulting 
accepted proposal is:

Proposal F:

   : 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.
   :
   : <MovedFrom9.2.1><DEL>Each block-level element generates</DEL>
   : <INS>Certain values of the 'display' property cause an element of
   : the source document to generate</INS> a
   : *principal <DEL>block-level</DEL> box* that contains descendant
   : boxes and generated content and is also the box involved in any
   : positioning scheme. Some <DEL>block-level</DEL> 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.</MovedFrom9.2.1>
   :
   : 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> <INS> – are elements which generate a
   : 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'. <MovedFromBelow>*Block-level boxes* are
   : boxes that participate in a
   : _block formatting context_.</MovedFromBelow>
   :
   : <MovedToAbove>Block-level boxes are boxes that participate in a
   : block formatting context.</MovedToAbove> <MovedTo9.2>Each
   : block-level element generates a principal block-level 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.</MovedTo9.2>
   :
   : <DEL>Except for table boxes, which are described in a later
   : chapter, and replaced elements, a block-level box is also a block
   : container box.</DEL> <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>. <INS>An element whose
   : principal box is a block container box is a
   : *block container element*. Values of the 'display' property that
   : make a non-replaced element generate a block container include
   : 'block', 'list-item' and 'inline-block'.</INS> Not all block
   : container boxes are block-level boxes: non-replaced inline blocks
   : and non-replaced table cells are block containers but
   : <INS>are</INS> not block-level <DEL>boxes</DEL>. <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> Block-level boxes that are also block
   : containers are called block boxes.
   :
   : The three terms "block-level box," "block container box," and
   : "block box" are sometimes abbreviated as "block" where unambiguous.


   : 9.2.4 The 'display' property
   :
   : [...]
   :
   : The values of this property have the following meanings:
   :
   : block
   :   This value causes an element to generate a <INS>principal</INS>
   :   block box.
   :
   : inline-block
   :   This value causes an element to generate <DEL>an</DEL>
   :   <INS>a principal</INS> inline-level block container.
   :   <INS>(</INS>The inside of an inline-block is formatted as a block
   :   box, and the element itself is formatted as an atomic
   :   inline-level box.<INS>)</INS>


   : 17.4 Tables in the visual formatting model
   :
   : In terms of the visual formatting model, a table can behave
   : like a block-level (for 'display: table') or inline-level (for
   : 'display: inline-table') element.
   :
   : In both cases, the table generates a principal block
   : <INS>container</INS> box called the table wrapper box that
   : contains the table box itself and any caption boxes (in
   : document order). The table box is a block-level box that contains
   : the table's internal table boxes. The caption boxes are
   : <INS>principal</INS> block-level boxes that retain their own
   : content, padding, margin, and border areas, and are rendered as
   : normal block boxes inside the table wrapper box. Whether the
   : caption boxes are placed before or after the table box is decided
   : by the 'caption-side' property, as described below.
   :
   : The table wrapper box is <DEL>a 'block' box if the table is
   : block-level</DEL> <INS>block-level for 'display: table'</INS>, and
   : <DEL>an 'inline-block' box if the table is inline-level</DEL>
   : <INS>inline-level for 'display: inline-table'</INS>. [...]


[1] http://lists.w3.org/Archives/Public/www-style...
[2] https://www.w3.org/Bugs/Public/show_bug.cgi?i...

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

On Thu, Sep 20, 2012 at 10:25:30AM +0200, Anton Prowse wrote:

> (and we regard the "multiple inline boxes" described by
> CSS21 as being the result of fragmentation across different line
> boxes),Note that a similar situation occurs when a block element is split over
multiple pages.

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.>   : 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 while inline-block is inline-level, and table-* (including
table-caption) are neither; 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").  The "form new blocks of content" wording
in §9.2.2 is quite good, especially if accompanied by such a "first
approximation" qualifier.

I know it's not important.

>   : <INS> – are elements which generate a

(I think fantasai already suggested s/which/that/ here, but if that was
elsewhere then I do suggest it here too.)>   : 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.  (Sorry, I haven't checked.)  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.  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.>   : <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), 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.>   : <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", and I'd be inclined to clarify the
distinction between (inner) "table box" and table elements (which generate a
block-container table wrapper box).  Addressing either one of these issues
makes the other less important to address.>   : 17.4 Tables in the visual formatting model
>   :
>   : In terms of the visual formatting model, a table can behave
>   : like a block-level (for 'display: table') or inline-level (for
>   : 'display: inline-table') element.
>   :
>   : In both cases, the table generates a principal block
>   : <INS>container</INS> box called the table wrapper box thatGood, that change looks like it should go in regardless of the rest of the
proposal.>   : The caption boxes are
>   : <INS>principal</INS> block-level boxes that retain their ownFor 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.

(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 isn't a strong objection, it's just something that makes me stop to
think what it means when reading it.


No other comments.

pjrm.

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-levelCSS21 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 therelevant 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

On Mon, Oct 08, 2012 at 06:45:06PM +0200, Anton Prowse wrote:

> > [erroneous inclusion of 'table-caption' among set of block-level-like
> >  things that aren't in fact block-level.]
>
> 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.(No, sorry, I was just getting confused by the existing text in visuren.html,
 which to me reads as saying that it isn't block-level.  tables.html is clear
 that table-caption is block-level, but isn't referenced by the text that
 currently defines that term.)> > That's in any case an outstanding issue with the table stuff, from memory:
> > [...]

> 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.By what criteria should content of CSS 2.1 be considered unacceptable,
or what criteria make a proposed change worth making?

Technical soundness (or its lack) used to be a sufficient criterion for
change, but it's been clear since before CSS 2.1 became a Recommendation
that that's no longer sufficient grounds to change this spec.  (E.g. the
above "this chapter is so broken that it isn't worth fixing in this spec.")

Without some clear criterion such as technical soundness, it's hard to know
what errors should be reported, or what information should be mentioned when
discussing issues on this mailing list, or even whether it's worth reporting
errors.

pjrm.

On 11/10/2012 08:02, Peter Moulder wrote:
> On Mon, Oct 08, 2012 at 06:45:06PM +0200, Anton Prowse wrote:
>>> That's in any case an outstanding issue with the table stuff, from memory:
>>> [...]
>
>> 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.
>
> By what criteria should content of CSS 2.1 be considered unacceptable,
> or what criteria make a proposed change worth making?
>
> Technical soundness (or its lack) used to be a sufficient criterion for
> change, but it's been clear since before CSS 2.1 became a Recommendation
> that that's no longer sufficient grounds to change this spec.  (E.g. the
> above "this chapter is so broken that it isn't worth fixing in this spec.")
>
> Without some clear criterion such as technical soundness, it's hard to know
> what errors should be reported, or what information should be mentioned when
> discussing issues on this mailing list, or even whether it's worth reporting
> errors.I understand your concerns, and let me try to address them.

In terms of (not) working on tables for CSS21-errata, I was referring to 
me personally rather than speaking for the WG.  My personal opinion is 
that time would be better spent actually doing css3-tables rather than 
trying to patch up the CSS21 Tables chapter.  (Perhaps css3-tables prose 
could then be ported back to CSS21 for errata.)  Others in the WG might 
feel differently.

In terms of which issues people should bring to the mailing list, I 
encourage everyone to bring all issues.  I recognize it can be 
frustrating to bring an issue and be told it's unlikely to be a 
priority; it's happened to me more than a few times, too!  But I 
wouldn't like to encourage anyone to try to "second-guess" which issues 
will meet that response.  All issues are worth being raised in the open.

In terms of which issues are likely to be addressed for CSS21 in errata 
rather than being punted to future levels, I don't have any 
hard-and-fast criteria and I don't believe anyone else the the WG does 
either.  (Certainly, I've never seen anything written down.)  I do think 
it's important to recognize that the spec is already a REC.  Just as a 
book publisher has to make the call whether to issue an erratum or wait 
until the publication of a future edition, so the WG has to make a call 
whether to issue CSS21 errata or wait until CSS3.  In both cases, 
issuing errata has overhead, much more than just fixing the issue prior 
to publication.  Personally, I run with something like "things that are 
confusing but not actually contradictory, wrong or lead to technical 
ambiguities" will most likely be pushed to CSS3".

In the case of the specific tables issue you raised, I see that my reply 
was a bit misleading.  I was specifically saying that I don't have a 
record of the post whether the issue was raised, implying - but I should 
have stated it clearly - that it would be great if you could send one so 
that I can add it to the issues pile.  (Even if I think that an issue is 
unlikely to be addressed for CSS21, my tactic is to add issues to the 
list if there seems to be any possibility that the editors of the future 
spec that would cover the issue might overlook it.)

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

On Thu, Sep 20, 2012 at 10:25:30AM +0200, Anton Prowse wrote:

>   : <MovedFromBelow>*Block-level boxes* are
>   : boxes that participate in a
>   : _block formatting context_.</MovedFromBelow>I previously wrote that I suspected that this definition is circular, but
that I hadn't checked.  I now have checked, and have written up my findings
in a new thread, entitled ‘[CSS21] How to define "block-level box"’.  (I
didn't look into the circular aspect as might be introduced by §9.2.1.1's
reliance on the definition of block-level, but I did find a more immediate
problem arising from defining block-level in terms of participation in a
block formatting context.)

One could say that the problem is irrelevant to this proposal, since it
exists whether or not the proposal is adopted.  On the other hand,
addressing the block-level problem (at least if in the manner I proposed in
that message) would involve changes to the text introduced by this
proposal.

pjrm.

Regarding a proposed addition to 9.2.1 (Block-level elements and block 
boxes),On 25/07/2012 08:23, fantasai wrote:
>  | Unless a block box `establishes a new formatting context`_,
>  | its contents participate its containing block formatting context.
>
> [The proposed addition] fixes a missing idea that's already clear wrt
> inline boxes. Though
>    "participate in its containing block formatting context"
> is a little awkward, given we have the term "containing block". It's
> meant to parallel the similar statement in 9.2.2. We could replace both
> with
>    "participate in the same XXX formatting context as the XXX box itself"
> to be clearer.Yes, the spec fails to say that each block-level box participates in its 
*closest ancestor* block formatting context.

I'm not sure about using "its contents participate" though.  Any 
inline-level children participate in the inline formatting context that 
the block box establishes, not in the ancestor block formatting context.

I think using "its block-level contents participate" is enough to fix that.

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

> On 15/07/2012 01:12, Anton Prowse wrote:
> The term "Block container element" is not defined in CSS21 (although
>> block container /box/ is, in 9.2.1.).  Several participants on this list
>> have expressed concern about this in the past.
>
>> I propose the following insertions/deletions to 9.2.1.  The changes are
>> limited to shuffling a couple of existing sentences around (untouched)
>> and introducing just two new concepts:
>>
>> (1) The definition of "principal block-level box" is extended to
>> "principal box" for a wider range of elements (inline block, inline
>> table and table cell in addition to block-level elements).  This has no
>> effect on the rest of the spec, since the only cases where the principal
>> box is referred to is in the context of block-level elements/boxes.
>>
>> (2) The term "block container element" is introduced to mean an element
>> whose principal box is a block container box, ie a block, list-item,
>> inline-block, table, inline-table or table-cell in CSS21.In [1], in response to the proposal in [2], Alan Stearns asks:> Should table-caption also be on the list [of elements which are
> block  container elements]?Table captions are necessarily block-level, so are already included.

> Is a ::before {display:block} a "block container element"?

CSS21 uses the word "element" in a way which includes pseudo-elements. 
So the question is really asking, can pseudo-elements generate a 
principal box?  I feel that they can/should, depending on their display 
type of course.  Do you see any potential issues with that?


[1] https://www.w3.org/Bugs/Public/show_bug.cgi?i...
[2] https://www.w3.org/Bugs/Public/show_bug.cgi?i...

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

On 8/1/12 11:24 PM, "Anton Prowse"  wrote:

>> On 15/07/2012 01:12, Anton Prowse wrote:
>> The term "Block container element" is not defined in CSS21 (although
>>> block container /box/ is, in 9.2.1.).  Several participants on this
>>>list
>>> have expressed concern about this in the past.
>>
>>> I propose the following insertions/deletions to 9.2.1.  The changes are
>>> limited to shuffling a couple of existing sentences around (untouched)
>>> and introducing just two new concepts:
>>>
>>> (1) The definition of "principal block-level box" is extended to
>>> "principal box" for a wider range of elements (inline block, inline
>>> table and table cell in addition to block-level elements).  This has no
>>> effect on the rest of the spec, since the only cases where the
>>>principal
>>> box is referred to is in the context of block-level elements/boxes.
>>>
>>> (2) The term "block container element" is introduced to mean an element
>>> whose principal box is a block container box, ie a block, list-item,
>>> inline-block, table, inline-table or table-cell in CSS21.
>
>In [1], in response to the proposal in [2], Alan Stearns asks:
>
>> Should table-caption also be on the list [of elements which are
>> block  container elements]?
>
>Table captions are necessarily block-level, so are already included.Thanks. I should have been more specific about which list. The list I was
referring to is this one:

# The following
  # values of the 'display' property make a non-replaced element a
  # block container: 'block', 'list-item', 'table', 'inline-block',
  # 'inline-table', 'table-cell'.


I meant to point out that 'table-caption' is a value of 'display' that
makes a non-replaced element a block container. So it should probably be
included in this list.>
>> Is a ::before {display:block} a "block container element"?
>
>CSS21 uses the word "element" in a way which includes pseudo-elements.
>So the question is really asking, can pseudo-elements generate a
>principal box?  I feel that they can/should, depending on their display
>type of course.  Do you see any potential issues with that?No issue - I was unclear whether "element" included pseudo-elements.
Thanks for the clarification.

Alan

On 02/08/2012 15:47, Alan Stearns wrote:
> On 8/1/12 11:24 PM, "Anton Prowse"  wrote:
>
>>> On 15/07/2012 01:12, Anton Prowse wrote:
>>> The term "Block container element" is not defined in CSS21 (although
>>>> block container /box/ is, in 9.2.1.).  Several participants on this
>>>> list
>>>> have expressed concern about this in the past.
>>>
>>>> I propose the following insertions/deletions to 9.2.1.  The changes are
>>>> limited to shuffling a couple of existing sentences around (untouched)
>>>> and introducing just two new concepts:
>>>>
>>>> (1) The definition of "principal block-level box" is extended to
>>>> "principal box" for a wider range of elements (inline block, inline
>>>> table and table cell in addition to block-level elements).  This has no
>>>> effect on the rest of the spec, since the only cases where the
>>>> principal
>>>> box is referred to is in the context of block-level elements/boxes.
>>>>
>>>> (2) The term "block container element" is introduced to mean an element
>>>> whose principal box is a block container box, ie a block, list-item,
>>>> inline-block, table, inline-table or table-cell in CSS21.
>>
>> In [1], in response to the proposal in [2], Alan Stearns asks:
>>
>>> Should table-caption also be on the list [of elements which are
>>> block  container elements]?
>>
>> Table captions are necessarily block-level, so are already included.
>
> Thanks. I should have been more specific about which list. The list I was
> referring to is this one:
>
> # The following
>    # values of the 'display' property make a non-replaced element a
>    # block container: 'block', 'list-item', 'table', 'inline-block',
>    # 'inline-table', 'table-cell'.
>Ah, well spotted!  It should.

[Aside:

I had created my list of display types by augmenting the list of 
block-level display types that's already given in 9.2.1 with the new 
stuff that would give rise to a principal box (namely inline block, 
inline table and table cell).  My mistake lay in forgetting that said 
list is itself incomplete!  From [1]:fantasai writes:
> On 07/29/2010 02:35 PM, Boris Zbarsky wrote:
>> Anton Prowse wrote:
>>> [...] table-caption elements need to be included in the
>>> classification of block-level elements in 9.2.1.
>>
>> Agreed.
>
> Table-caption elements are explicitly defined to be block-level elements
> in 17.4, so this is already unambiguous. We could also add them to 9.2.1;
> however, I don't think this is a good idea because in the future we'll
> have caption-side: left | right again, and the behavior there is not really
> the behavior of a block-level element.Is the incompleteness of the list of block-level elements too confusing? 
  I tend to think it is, although of course I see the point that 
fantasai was making.

Perhaps we could get rid of that list as follows.  We could define a 
block-level element as being an element whose principal box is 
block-level, and rely on (and expand out the "block-level elements" bit 
of) my newly-introduced and complete list of display types which cause 
an element to generate a principal box.  That's easy to do, and it 
allays fantasai's concern (since a table caption will generate a 
principal box irrespective of the fact that it might not be block-level 
in some future spec), and it also addresses Peter Moulder's observation 
in [2] that 17.4 actually fails to say that table-caption *elements* are 
block-level in CSS21.

This will be the subject of a separate errata item, though.]On 02/08/2012 15:47, Alan Stearns wrote:
> On 8/1/12 11:24 PM, "Anton Prowse"  wrote:
>> Alan Stearns asks:
>>>
>>> Is a ::before {display:block} a "block container element"?
>>
>> CSS21 uses the word "element" in a way which includes pseudo-elements.
>> So the question is really asking, can pseudo-elements generate a
>> principal box?  I feel that they can/should, depending on their display
>> type of course.  Do you see any potential issues with that?
>
> No issue - I was unclear whether "element" included pseudo-elements.
> Thanks for the clarification.OK, cool.


[1] http://lists.w3.org/Archives/Public/www-style...
[2] http://lists.w3.org/Archives/Public/www-style...

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