Re: [CSS21] z-index-020 test case is invalid

On Wed, 26 Oct 2011 23:21:21 +0200, Arron Eicholz  
<Arron.Eicholz@microsoft.com> wrote:

> On Wednesday, October 26, 2011 3:50 AM Øyvind Stenhaug wrote:
>> On Wed, 26 Oct 2011 02:23:08 +0200, Arron Eicholz
>> <Arron.Eicholz@microsoft.com> wrote:
>>
>> > http://test.csswg.org/suites/css2.1/20110323/html4/z-index-020.htm
>> >
>> > http://www.w3.org/TR/CSS21/zindex.html
>> (...)
>>
>> > o   The remaining steps 3-10 do not apply since there are no matching
>> > descendants. This means we unwind out of this section and go back to
>> > the DIV (test container) steps.
>> >
>> > ·         Step 6: There are no inline elements in DIV (test container)
>> >
>> > ·         Step 7: We first come across DIV (outline) as the first
>> > candidate (in tree order) that falls into this step.
>>
>> I don't think this is at all obvious. It says "first for the element,  
>> then for all its
>> in-flow, non-positioned, block-level descendants in tree order". So  
>> first the
>> steps are performed for .container, and then we get to step 7.2.1: "For  
>> each
>> box that is a child of that element, in that line box, in tree order".
>
> Step 7 is the catch all case for catching everything else that doesn't  
> fall into any other cases. "first for the element" in this case means  
> what should I do with DIV (outline)? We are already processing the DIV  
> (test container) as it was a step 8 case which created a stacking  
> context and stared over from step 1 for its contents.

We are processing the test container DIV, yes, which means .container is  
currently what "the element" references.

>>
>> > o   Steps 7.1, 7.2: don't apply since the DIV (outline) only has an
>> > outline.
>> >
>> > o   Step 7.3: Paint the outline for the block level element DIV
>> > (outline) this will draw on top of the blue box DIV (float)
>> >
>> > ·         Step 7: There are other candidates that we need to consider
>> > (in tree order) we need to handle DIV (inline).
>>
>> No, that doesn't work. The .inline div is not an "in-flow,  
>> non-positioned,
>> block-level descendant".
>
> Yes, you are correct DIV (inline) is not an "in-flow, non-positioned,  
> block-level descendant". It doesn't have to be. You missed part of step  
> 7. It says Otherwise first for the element which means you need to  
> handle DIV (inline) and then is says for its block-level descendants in  
> tree order.

We are still handling the .container (these top-level steps are performed  
for any element that generates a stacking context), so "the element" is  
still .container, not .inline.

> Well DIV (inline) has no descendants but you still need to handle DIV  
> (inline) here. If you don't handle it here there is no place to draw  
> this element at all so that is why this is a catch all case.

Yes there is, when reaching step 7 for .container it's supposed to explain  
how to draw the inline-level descendants of .container, in 7.2.1.

> Note that Opera is already correct in that it paints it outlines as part  
> of Step 10 which is the recommended but not required location. I am  
> arguing for correcting the optional location painting in the reference  
> image because right now the reference is incorrect for the optional  
> solution.

I agree that, given the placement of 7.2.5 (after David's correction)  
right after the step where text gets drawn, and given how browsers  
actually paint text in an inline-block child vs. block-level children, it  
looks like the behavior intended to be specified in the text might be such  
that the outline in this test case may be painted before the aqua  
inline-block background. I just think that it can't be proved by stepping  
through appendix E in detail, because it seems to fall apart when one  
looks at it too closely.

(This would of course be a spec issue, I just haven't had time yet to  
check if there already relevant reports on this particular step.)

-- 
Øyvind Stenhaug
Core Norway, Opera Software ASA

Received on Thursday, 27 October 2011 13:26:38 UTC