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

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.

[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.]


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

> To understand whether UAs match that in reality, we
> need a test case in which a table caption is positioned with negative
> z-index (thus treated in Step 3) to overlap with the table box.

This issue is filed at 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17782 , along with a test 
case which demonstrates that none of Gecko, Webkit, Presto and Trident 
paint the table box prior to descendent stacking contexts (table 
captions) with negative stack levels; and hence my proposed change 
above, which involves a shift to Step 4, matches reality.


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

Received on Saturday, 14 July 2012 22:38:55 UTC