W3C home > Mailing lists > Public > www-style@w3.org > April 2010

RE: [CSS21] stack level definitions in 9.9.1

From: Sylvain Galineau <sylvaing@microsoft.com>
Date: Fri, 2 Apr 2010 00:08:42 +0000
To: Anton Prowse <prowse@moonhenge.net>
CC: "www-style@w3.org" <www-style@w3.org>
Message-ID: <045A765940533D4CA4933A4A7E32597E211E2C8E@TK5EX14MBXC113.redmond.corp.microsoft.com>
Anton, the following will skip over the items in your response [a] that we agree on 
and work through the rest. Given the lengths of our respective responses I will
limit myself to some comments and a second proposal.

It is worth repeating that in the absence of testcases demonstrating interoperability
issues I intend to keep editing changes to a reasonable minimum. This also will be
my last attempt at coming to a resolution on the full set of issues you have reported. 
If we are unable to find agreement then I will recommend to the WG that we fix the 
one clear prose error (the 'floats and their contents' in 9.9.1's painting layer 4) and 
leave the rest of the prose unchanged. If the CSS2.1 prose is too hard to fix without 
a more extensive rewrite then I am personally much more comfortable attempting such
a rewrite in a Level 3 module rather than risking the introduction of contradiction(s) 
between CSS2.1 and existing implementations. 

This being said, I certainly agree that this relatively complex area deserves improvement
and your considerable efforts are very much appreciated. Thus, the shortcomings of my
response as well as any inability to find consensus are mine only.

Now, some general comments:
- I will not attempt to resolve the stack level vs. z-index terminology issue. I do not 
consider 'stack level' to be burdensome or defined at 'great lengths', nor do I consider its 
usage frequency to be relevant to the overall issue. Given that the term does exist, as
well as a goal of minimal editorial changes, I am, however, interested in eliminating 
possible confusion as to its meaning. 
- Your point about 9.5., floats and their in-flow inline content is, in my opinion, implicitly 
addressed by the high-level overview of painting layers in 9.9.1. (in-flow inline-level 
non-positioned *descendants* are just that; if the meaning of descendant is not clear at 
this stage of the spec, we have a much bigger problem than fixing this section)

[a] http://lists.w3.org/Archives/Public/www-style/2010Mar/0470.html


1. In section 9.9.1 [1], replace:
      # Each box in a given stacking context has an integer stack level, which is its 
      # position on the z-axis relative to other boxes in the same stacking context.
   with
      # Each positioned box in a given stacking context has an integer stack level, which is its 
      # position on the z-axis relative to other stack levels within the same stacking context.

2. In section 9.9.1 [1], replace:
      # 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.
            # 3.a stacking level containing in-flow non-inline-level non-positioned descendants.
            # 4.a stacking level for non-positioned floats and their contents.
            # 5.a stacking level for in-flow inline-level non-positioned descendants.
            # 6.a stacking level for positioned descendants with 'z-index: auto', and any descendant 
            # stacking contexts with 'z-index: 0'.
            # 7.the stacking contexts of descendants with positive stack levels.
      # For a more thorough explanation of the stacking order, please see Appendix E.
   with
      # Within each stacking context, the following layers are painted in back-to-front
      # order:
            # 1.the background and borders of the element forming the stacking context.
            # 2.the stacking contexts of descendants with negative stack levels.
            # 3.in-flow non-inline-level non-positioned descendants.
            # 4.non-positioned floats.
            # 5.in-flow inline-level non-positioned descendants.
            # 6.positioned descendants with 'z-index: auto', and any descendant stacking 
            # contexts with 'z-index: 0'.
            # 7.positioned descendants with positive stack levels.
      # This painting order is applied recursively to each stacking context in document 
      # tree order. This description of stacking context painting order constitutes an 
      # overview of the detailed normative definition in Appendix E.
3. 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 stack level 
      # of all the other elements in the stacking context is then resolved at rendering time
      # using the painting order below.
	
4. 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...

[1] http://www.w3.org/TR/CSS21/visuren.html#z-index
[2] http://www.w3.org/TR/CSS21/zindex.html
Received on Friday, 2 April 2010 00:09:18 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:26 GMT