Re: [CSS21] stack level definitions in 9.9.1

(The following aims to address issue 60 : http://wiki.csswg.org/spec/css2.1#issue-60)

Due to the volume of input provided for this issue[a][b][c], I will first summarize the *minimal* 
set of changes I believe to be necessary to resolve it.

1. In section 9.9.1 [1], replace:
      # 4.a stacking level for non-positioned floats and their contents.
   with:
      # 4.a stacking level for non-positioned floats.

2. In section 9.9.1 [1], replace:
      # 2.the stacking contexts of descendants with negative stack levels.  
   with:	 
      # 2.the stacking contexts of positioned descendants with non-zero negative z-index in
      # z-index order (most negative first).

3. In section 9.9.1 [1], replace:
      # 7.the stacking contexts of descendants with positive stack levels.
   with
      # 7.the stacking contexts of positioned descendants with non-zero positive z-index in
      # z-index order (1 first).

4. In Appendix E, E.2 [2], replace:
      # The stacking context background and most negative positioned stacking contexts are 
      # at the bottom of the stack, while the most positive positioned stacking contexts are 
      # at the top of the stack.
   with:
      # The stacking context's background is at the bottom of the stack, immediately below its 
      # descendant stacking context with the most negative z-index. The descendant stacking 
      # context with the highest positive z-index is at the top of the stack. The stacking level 
      # of all the other elements in the stacking context is defined by the painting order below.
	
5. In Appendix E, E.2 [2], replace:
      # The stacking order for an element generating a stacking context... 
    with:
      # The painting order for the descendants of an element generating a stacking context...

Background
----------
Stacking contexts is currently described in 9.9.1 [1] and Appendix E [2]. Both sections are 
normative and address the same topic with a significantly different levels of details. To an 
extent, one could see Appendix E as the implementor version of a more author-oriented 9.9.1. 

As much of the feedback describes differences between these two versions, the WG should 
Discuss whether it would be appropriate to have 9.9.1 refer to Appendix E for all painting 
order information. My personal preference is to maintain the flow and readability of this 
spec of the document by preserving an accurate higher-level version of Appendix E. 

Both [a] and subsequent elaboration [aa] deal with terminology confusion; in 9.9.1, the term 
'stacking level' is used to describe both discrete integer z-index values as well as painting 
layers:
      
      # This integer is the stack level of the generated box in the current stacking context.
      ...
      # Each stacking context consists of the following stacking levels (from back to front): 
         # 1.the background and borders of the element forming the stacking context.
         # 2.the stacking contexts of descendants with negative stack levels.

So stacking level #2 is made of those elements with a negative stack level that are....on top of 
stack level #1. What the prose is really saying is the second stacking level is where positioned 
descendants with negative z-index are painted in z-index order starting from the most negative. 

Then in Appendix E, the 'stacking level' term disappears and becomes 'stacking order', under a 
paragraph heading of 'Painting order'.

Changes in #2 and #3 are meant to precise and align 9.9.1 stacking level descriptions with Appendix E's. 
Change #4 gets rid of 'positioned' as a way to describe stacking level as it seems inappropriate here 
and reintroduces stacking level as a synonym for 'layer in the painting order'. Change #5 aims to be 
a more precise description of what follows.


Regarding [b], most of the issues raised are editorial:
- Problem 2.1: the issue is editorial
- Problem 2.2: the issue is editorial
- Problem 2.3: the issue is editorial
- Problem 2.4: the issue is editorial
- Problem 2.5: the issue is editorial
- Problem 2.6: the issue is editorial
- Problem 2.7: the issue is editorial
- Problem 2.8: the issue states that the painting order of non-positioned/z-index:auto elements within 
a stacking context is not defined in 9.9.1. It is addressed below.
- Problem 2.9: this issue is editorial and essentially the same as the original issue raised in [a] and 
addressed in changes 2-5  above.
- Problem 2.10: this issue relates to the position of floated elements' content in the painting order. 
It is addressed below through testcases [c.1] and [c.2]. It also asks whether the painting order level 
for float includes all floats or non-positioned floats only. The fix recommended by Ian [7] to address 
the latter has already been applied to the spec. 
- Problem 2.11: this issue is a typo in 9.5 also mentioned in [d] that is fixed in the latest version 
of the specification [3]

I do not recommend resolving the issues deemed editorial above as proposed. While the prose *can* be 
rewritten as suggested, the WG needs evidence of the *need* to accept the extensive proposed rewrites 
[4][5] together with new terminology ('strong stacking contexts', 'painting context', 'containing painting
context') in this already relatively complex area.

L. David Baron requested testcases thus [6] :
> A testcase that one part of the spec says should be displayed in one  
> way and another part says should be displayed another way is  
> evidence of an error in the spec.  A testcase that the spec says  
> should be displayed one way but you believe should be displayed a  
> different way indicates a potential error in the spec (if your  
> belief is correct).
>
> Without one of those types of testcases, you haven't demonstrated an  
> error in the spec in a way that we can understand.

Testcases were then offered in [c]:

- The issue raised  by the first testcase [c.1] is addressed by recommended change #1 above.
- The issue raised by the second testcase [c.2] is also addressed by change #1.
- The third testcase [c.3] is a testcase for problem 2.8 in [b]. The testcase states that the prose in 9.9.1 
does not allow the red inline to be on top of the green float. This seems incorrect since the painting order 
defined in 9.9.1 is back-to-front and non-positioned floats (#4) precede in-flow inline-level non-positioned 
descendants. Further, it is unclear why a computed numeric value needs to be assigned to the z-index property 
for these elements since a) the property only applies to positioned elements and b) neither the span or float 
in the testcase establish a stacking context. The painting order stacks described in 9.9.1 and Appendix E agree 
on their proper position. All major browsers render this testcase interoperably.


[a] http://lists.w3.org/Archives/Public/www-style/2007Dec/0001.html
[aa] http://lists.w3.org/Archives/Public/www-style/2008Jan/0057.html
[b] http://dev.moonhenge.net/css21/spec/z-index/
[c] http://lists.w3.org/Archives/Public/www-style/2008Oct/0263.html
[d] http://lists.w3.org/Archives/Public/www-style/2008Oct/0238.html
[c.1] http://dev.moonhenge.net/css21/spec/z-index/testcases/stacking-level-for-floats.html
[c.2] http://dev.moonhenge.net/css21/spec/z-index/testcases/stacking-level-for-floats-2.html
[c.3] http://dev.moonhenge.net/css21/spec/z-index/#stack-level-non-pos
[1] http://www.w3.org/TR/CSS21/visuren.html#z-index
[2] http://www.w3.org/TR/CSS21/zindex.html
[3] http://www.w3.org/TR/CSS21/
[4] http://dev.moonhenge.net/css21/spec/z-index/css21_zindex_proposal1.html
[5] http://dev.moonhenge.net/css21/spec/z-index/css21_zindex_proposal2.html
[6] http://lists.w3.org/Archives/Public/www-style/2008Oct/0257.html
[7] http://lists.w3.org/Archives/Public/www-style/2008Oct/0240.html

Received on Thursday, 25 March 2010 18:59:24 UTC