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

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.

As I read it, inline-blocks and inline-tables which establish stacking 
contexts don't get their backgrounds painted at all in the algorithm, 
unless they're covered by "block equivalent" in Step 2.

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:

(Note the line break, which I think adds needed clarity).  Note that the 
suggested replacement in the latter case has a dependency on 
http://lists.w3.org/Archives/Public/www-style/2012May/0497.html .


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


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

Received on Monday, 14 May 2012 22:06:03 UTC