Re: [CSS21] (Appendix E) Are inline-blocks "block equivalent"?

On 15/07/2012 00:38, Anton Prowse wrote:
> On 15/05/2012 00:05, Anton Prowse wrote:
>> On 11/05/2012 16:07, Simon Sapin wrote:
>>> Appendix E uses this sentence twice:
>>> "If the element is a block, list-item, or other block equivalent"
>>>
>>> What is a "block equivalent"? Do inline-blocks fall in that category?
>>>
>>> I’m trying to figure out how to make sure that inline-blocks (that may
>>> or may not be positioned, with z-index that may or may not be 'auto')
>>> get their background and borders painted exactly once...
>>
>> Yes, this does seem a bit muddled, doesn't it.
>
> This issue is now filed at
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=17778
>
>> I think Step 2 should in fact be talking about block containers.
>>
>> Replace:
>>    # Step 2: If the element is a block, list-item, or other block
>>    #         equivalent:
>> with
>>    | Step 2: If the element is a block container or block-level replaced
>>    |         element:
>>
>> Similarly, replace:
>>    # Step 4: For all its in-flow, non-positioned, block-level
>>    #         descendants in tree order: If the element is a block,
>>    #         list-item, or other block equivalent:
>> with:
>>    | Step 4: For all its in-flow, non-positioned, block-level
>>    |         descendants in tree order:
>>    |         If the element is a block container or replaced element:
>>
>
> Actually, that's not enough to exclude block-level tables from these
> parts of Steps 2 and 4, since such tables are block container elements
> (in that their principal table wrapper box is a block container box).
>
> In theory we'd need to explicitly exclude block-level tables from these
> parts.  However, the proposal below, which modifies Steps 2 and 4 to fix
> a different bug concerning the painting order of table components,
> removes the problem.

>> On a related note, the second list of Step 2 which purportedly applies
>> to stacking contexts which are block-level tables is nonsensical: the
>> list is clearly talking about the table box, yet in CSS21 a table box
>> cannot be a stacking context (since the 'position' property affects the
>> table wrapper box instead).  This is a left-over from the days when
>> there was confusion between the table wrapper box (which may be
>> block-level or inline-level) and the (always block-level) table box.
>>
>> Potentially, this problem is solved by deleting the following section
>> from Step 2:
>>    # Otherwise, if the element is a block level table:
>>    #
>>    # 1. table backgrounds (color then image) unless it is the root
>>    #    element.
>>    # [...]
>>    # 7. all table borders (in tree order for separated borders).
>>
>> I say potentially, because these details would be handled by the
>> identical section in Step 4 instead, with the only difference being the
>> location in the algorithm at which they are handled.  Hence the change
>> is potentially breaking one, but I think I'm proposing what the spec
>> author intended.
>
> I offer a new proposal, which switches the order of the two parts of
> Steps 2 and 4 (thus working around the issue described above) and
> untangles another box vs element knot:
>
> In Step 2, replace:
>
>    # If the element is a block, list-item, or other block equivalent:
>    #   [...]
>    #
>    # Otherwise, if the element is a block level table:
>    #   1. table backgrounds (color then image) unless it is the root
>    #      element.
>    #   [...]
>    #   7. all table borders (in tree order for separated borders).
>
> with:
>
>    | If the element is a block level table, treat its table box as if
>    | it were its first child element in the steps which follow.
>    |
>    | Otherwise, if the element is a block container or block-level
>    | replaced element:
>    |   [...]
>
> In Step 4, replace:
>
>    # For all its in-flow, non-positioned, block-level descendants in
>    # tree order: If the element is a block, list-item, or other block
>    # equivalent:
>    #
>    #   1. background color of element.
>    #   2. background image of element.
>    #   3. border of element.
>    #
>    # Otherwise, the element is a table:
>    #
>    #   1. table backgrounds (color then image).
>    #   [...]
>    #   7. all table borders (in tree order for separated borders).
>
> with:
>
>    | For all its in-flow, non-positioned, block-level descendants in
>    | tree order:
>    | If the element is a table:
>    |
>    |   1. table backgrounds (color then image) unless it is derived from
>    |      the root element via _2_<link to Step 2>.
>    |   [...]
>    |   7. all table borders (in tree order for separated borders).
>    |
>    | Otherwise, the element is a block container or replaced element:
>    |
>    |   1. background color of element.
>    |   2. background image of element.
>    |   3. border of element.
>
> This modification continues to reflect the fact that we need to wait
> until Step 4 to paint the table box (since the table caption box might
> have a negative stack level and thus need to be painted in Step 3
> underneath the table box; see practical confirmation below), and it
> works around the fact that Step 4 is written in terms of descendant
> elements of the table element in question and is thus not immediately
> suitable for subsidiary /boxes/ of the element itself.

I had overlooked the fact that the term "element" is defined specially 
in E.1 to include certain boxes.  It would assist the proposals for both 
the issues with E.2 described above, and particularly the latter one, if 
we were to widen that definition slightly to include the table box 
generated by a table element - which seems likely to have been the 
author's intention anyhow.  (Similarly, the definition doesn't seem to 
include the marker box of a list item, and yet a subsequent sentence 
explicitly uses it as an example, so we can take the opportunity to 
clarify that at the same time.)  Note that this is effectively what my 
proposed extra wording for Step 2 was doing independently, in the 
proposal above.

So, for these bugs I make the following new proposal.

Proposal C:

In 9.2.1 (Block-level elements and block boxes), replace:

   # [...] Some block-level elements may generate additional boxes in 
addition to the principal box: 'list-item' elements. [...]

with:

   | [...] Some block-level elements may generate additional boxes in 
addition to the principal box: 'list-item' elements may generate a 
marker box, and table elements generate a _table box_<link to 17.4>. [...]

In E.1 (Definitions), replace:

   # Element
   #   In this description, "element" refers to actual elements,
   #   pseudo-elements, and anonymous boxes. Pseudo-elements and
   #   anonymous boxes are treated as descendants in the appropriate
   #   places. For example, an outside list marker comes before an
   #   adjoining ':before' box in the line box, which comes before the
   #   content of the box, and so forth.

with:

   # Element
   #   In this description, "element" refers to actual elements,
   #   pseudo-elements, marker boxes and table boxes _additionally
   #   generated_<link to 9.2.1> by list items and by block- and
   #   inline-level table elements respectively, and anonymous boxes.
   #   Pseudo-elements, additionally generated boxes and anonymous
   #   boxes are treated as descendants in the appropriate places.
   #   For example, a table box precedes a table caption, whilst
   #   an outside list marker comes before an adjoining ':before' box
   #   in the line box, which comes before the content of the box,
   #   and so forth.

In E.4 Step 2, replace:

   # If the element is a block, list-item, or other block equivalent:
   #   [...]

with:

   | If the element is a block container or block-level replaced
   | element:
   |   [...]

and delete:

   # Otherwise, if the element is a block level table:
   #   1. table backgrounds (color then image) unless it is the root
   #      element.
   #   [...]
   #   7. all table borders (in tree order for separated borders).

In E.2 Step 4, replace:

   # For all its in-flow, non-positioned, block-level descendants in
   # tree order: If the element is a block, list-item, or other block
   # equivalent:
   #
   #   [...]
   #
   # Otherwise, the element is a table:
   #
   #   1. table backgrounds (color then image).
   #   [...]
   #   7. all table borders (in tree order for separated borders).

with:

   | For all its in-flow, non-positioned, block-level descendants in
   | tree order:
   |
   | If the element is a block container or replaced element:
   |
   |   [...]
   |
   | Otherwise, the element is a table box:
   |
   |   1. table backgrounds (color then image) unless it is derived from
   |      the root element via _2_<link to Step 2>.
   |   [...]
   |   7. all table borders (in tree order for separated borders).

Note 1: the change to 9.2.1 links to 17.4 for table box because it would 
probably be naively assumed by the reader unfamiliar with tables that 
the table box is the principal box of a table element (which is false of 
course).  Note also that 9.2.1 is nominally about block-level tables, 
and so I haven't explicitly said that an inline-table element similarly 
generates an extra box; but I think it can be inferred, and of course my 
proposed change to E.1 indicates so explicitly by linking back to this 
section.  Ideally, my suggestion in [1] to define "block container 
element" and "principal box" of block container elements would be used 
to solve that problem completely, since then 9.2.1 would be saying that 
/block container elements/ may generate additional boxes, and we could 
call out inline tables alongside block-level tables.

Note 2: there's no longer any need to reorder the two parts of Steps 2 
and 4 since a table box is treated as a separate element, and it's not a 
block container.

Note 3: "the element is a table box" sounds weird, but given the special 
definition of element in E.1 it's actually correct.  It also serves to 
remind the reader that, in Appendix E at least, "element" isn't quite 
what it appears.


[1] http://lists.w3.org/Archives/Public/www-style/2012Jul/0338.html

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

Received on Wednesday, 18 July 2012 07:49:20 UTC