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

RE: [CSS21] stack level definitions in 9.9.1

From: Sylvain Galineau <sylvaing@microsoft.com>
Date: Fri, 14 May 2010 19:07:32 +0000
To: Anton Prowse <prowse@moonhenge.net>
CC: "www-style@w3.org" <www-style@w3.org>
Message-ID: <045A765940533D4CA4933A4A7E32597E2148C73D@TK5EX14MBXC120.redmond.corp.microsoft.com>
Anton,

Sorry it took me much longer than expected. The following is my attempt to 
combine your last proposals [1][2] with my own [3]. Explanation for the 
change - or lack of change from my initial proposal starts and ends with ***.

I am fully aware that this is less than you asked for, but this is as far
as I am comfortable going in CSS2.1 given both the WG's strong desire to
take it to REC and my own comfort level with this relatively complex area. 
I hope we can conclude with minimal changes to the list below.

Thanks !
S.


1. In section 9.9.1 [4], 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 [4], replace:
	#    auto
      #       [...].  The box does not establish a new local stacking
      #       context.
   with
      #    auto
      #       [...].  The box does not establish a new local stacking
      #       context unless it is the root element.


*** Your proposal regarding auto and '0' is not included here. I found 
it confusing as it could be read as conflicting with the description of 
layer 8 in Appendix E which does make a difference between auto/0 
positioned descendants. Coming from 9.9.1 knowing that "the stack level 
of 'auto' is '0'", the reader, will imo be very confused unless, maybe,
 E's #8 can be rewritten to prevent this ? (I'd rather touch E as lightly as 
I can, personally) . I also thought that defining 'auto' this way could be 
construed as saying z-index:auto computes to '0'. Which it doesn't today, 
thus unless we want to change all implementations we might have to find a 
way to say "it's 0 but it doesn't compute to that", none of which helps
comprehension. Overall, I didn't feel the issue warranted the risk of 
additional misunderstanding and thus extra caveats in what remains an
overview.

The overview will necessarily lack the precision of Appendix E. I am OK 
with that. And if parts of the overview are edited to reflect Appendix 
E but not others, I'm not sure it helps 9.9.1 readers ***

3. In section 9.9.1 [4], replace:
       # The contents of inline blocks and inline tables are stacked as
       # [...] They are then painted atomically in the inline stacking 
       # level.
    with
       # The contents of inline blocks and inline tables are stacked as
       # [...] They are then painted atomically in the inline painting 
       # layer (#5).

*** Likewise, your proposal #5 in [2] was a bit puzzling as it added 
non-positioned floats and z-index:auto to the list but then concluded with
'Such inline blocks and inline tables are painted...' which a) doesn't say 
where the other two are painted, for no clear reason and b) by the use of 
'such' could seem to conflate all four box types. And we also get back 
to the possible z-index:auto/z-index:0 confusion alluded to earlier. The 
suggested prose here reflects Appendix E's layer 8 distinction between 
auto and 0 but without clarifying or resolving it. 

I, however, took in your 'stacking level' to 'painting layer' change as 
it is consistent with the other terminology changes we agreed to.

Lastly, this change affects 9.9.1, not Appendix E. ***

3. 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 (most negative first).
             # 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.the stacking contexts of descendants with positive stack
             #   levels (least positive first).
       # This painting order is applied recursively to each stacking
       # context. This description of stacking context painting order
       # constitutes an overview of the detailed normative definition in
       # Appendix E.

*** Here, I took in all your suggested amendments as I found they were clear,
helpful and short and thus ideal for this overview ***


4. In Appendix E, E.2 [5], 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.
	
5. In Appendix E, E.2 [5], 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...

*** You agreed with these changes ***


[1] http://lists.w3.org/Archives/Public/www-style/2010Apr/0013.html
[2] http://lists.w3.org/Archives/Public/www-style/2010Apr/0365.html
[3] http://lists.w3.org/Archives/Public/www-style/2010Apr/0405.html
[4] http://www.w3.org/TR/CSS21/visuren.html#z-index
[5] http://www.w3.org/TR/CSS21/zindex.html
Received on Friday, 14 May 2010 19:08:09 GMT

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