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

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.

> 
> I can't even tell what this is supposed to say. The spec doesn't usually talk
> about boxes being children of elements (if anything it sometimes talks about
> boxes being children of other boxes, but doesn't actually define the
> formatting structure). I can make some sense of the steps by assuming "For
> each box that [is generated by] a child of that element [...]". But the way
> these steps drill down the tree and still just talk about "the/that element"
> necessitates a lot of interpretation.

I know how you can easily get confused. It took me over 3 hours to write the first mail confirming and double checking with people on my team to see that I actually understood what I was writing followed the spec.

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

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.

--
Thanks,
Arron Eicholz

Received on Wednesday, 26 October 2011 21:31:55 UTC