Re: [CSS21] stack level definitions in 9.9.1

Hi Sylvain,

Frustratingly, I unintentionally omitted an alternative to my amendment
1a when discussing your proposal #1 concerning stack level, which makes
my justification for my amendment 1b(i) unclear.  Sorry about that.

The following is a repeat of the whole of that section from my previous
post [A], revised with a minor modification to the analysis proceeding
the original amendment 1a and a corresponding update to that amendment
(now named 1a(i)), and also revised to include the alternative amendment
(named 1a(ii)) and to clarify my amendment 1b(i).  I have preserved my
original wording as far as possible, to aid you in case you wish to diff
this post with my last one.

Consequently, my concluding paragraph in [A] is now replaced by:

This concludes my list of proposed amendments to your latest proposal,
which I believe result in an accurate, coherent and reasonably
comprehensive 9.9.1.  Specifically, items 1,1b(ii),2,3,4,5, and either
1a(i) or both 1a(ii) and 1b(i), and also preferably 1c, exactly as
written in [A] except where updated in this current post, are what I
submit for consideration.

[A] http://lists.w3.org/Archives/Public/www-style/2010Apr/0365.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.

This, your latest proposal[d] for the clarification of the "stack level"
concept, succeeds in restricting "stack level" to being a friendly
façade for z-index, which I imagine was originally intended when it was
devised.  (It also resolves [b: 2.8].)

Note that it still states that each positioned box has an integer stack
level, which is not explicitly defined for z-index:auto boxes.  However,
the spec does say (in the definition of the z-index property) that the
stack level of such a box is "the same as its parent's box", and that
*provided that such a box has a closest positioned ancestor with integer
z-index* then such an ancestor "establishes a local stacking context in
which its stack level is '0'" which thus propagates this value '0' down
to the positioned descendants with z-index:auto. Whilst this
construction is somewhat bizarre, it is internally consistent (provided
that "parent's box" is interpreted as "closest positioned ancestor's
box", given that stack levels now only apply to positioned boxes).

We do, however, have the problem of what happens if a z-index:auto
positioned box doesn't actually have a positioned ancestor with integer
z-index. What should its integer stack level be? I suggest we accept
your proposal above and then amend 9.9.1 to ensure that /all/ positioned
z-index:auto boxes have stack level '0'. Note that this amendment will
not introduce unwanted contradictions or inaccuracies in 9.9.1 since
positioned boxes with z-index:auto or z-index:0 all share the same
painting layer. Furthermore, the spec states that "boxes with the same
stack level in a stacking context are stacked back-to-front according to
document tree order", which provides further motivation for the
amendment since clearly positioned boxes with z-index:auto or z-index:0
should be grouped together as far as that statement is concerned. Thus I
propose clarifying the definition of z-index as follows:

1a(i). In section 9.9.1 [1], replace:
       # Values have the following meanings:
       #    <integer>
       #       This integer is the stack level of the generated box in
       #       the current stacking context. The box also establishes a
       #       local stacking context in which its stack level is '0'.
       #    auto
       #       The stack level of the generated box in the current
       #       stacking context is the same as its parent's box. [...]
    with
       # Values have the following meanings:
       #    <integer>
       #       This integer is the stack level of the generated box in
       #       the current stacking context. The box also establishes a
       #       local stacking context in which its stack level is '0'.
       #    auto
       #       The stack level of the generated box in the current
       #       stacking context is the same as its closest positioned
       #       ancestor's box, or '0' if it does not have such an
       #       ancestor. [...]

As an alternative to the timid approach of the above amendment, we
could directly state that a z-index:auto positioned box has stack level
'0' irrespective of whether or not it has a positioned ancestor with
integer z-index (which is merely the result we end up with from the
awkward "local stacking context" concept and propagation construction
anyway):

1a(ii). In section 9.9.1 [1], replace:
       # Values have the following meanings:
       #    <integer>
       #       This integer is the stack level of the generated box in
       #       the current stacking context. The box also establishes a
       #       local stacking context in which its stack level is '0'.
       #    auto
       #       The stack level of the generated box in the current
       #       stacking context is the same as its parent's box. [...]
    with
       # Values have the following meanings:
       #    <integer>
       #       This integer is the stack level of the generated box in
       #       the current stacking context. The box also establishes a
       #       local stacking context in which its stack level is '0'.
       #    auto
       #       The stack level of the generated box in the current
       #       stacking context is '0'. [...]


If we are prepared to accept amendment 1a(ii) (and I think we do have to
accept either this, or 1a(i), or some other such amendment), we are then
free to remove the "local stacking context" concept and propagation
construction _without the need for further tweaks_: we merely remove the
occurrences of the word "local" and the corresponding phrase concerning
the resetting of the stack level from the definition of z-index:

1b(i). In section 9.9.1 [1], replace:
       # For a positioned box, the 'z-index' property specifies:
       #   1. The stack level of the box in the current stacking context.
       #   2. Whether the box establishes a local stacking context.
       #
       # Values have the following meanings:
       #    <integer>
       #       This integer is the stack level of the generated box in
       #       the current stacking context. The box also establishes a
       #       local stacking context in which its stack level is '0'.
       #    auto
       #       The stack level of the generated box in the current
       #       stacking context is the same as its parent's box. The box
       #       does not establish a new local stacking context.
    with:
       # For a positioned box, the 'z-index' property specifies:
       #   1. The stack level of the box in the current stacking context.
       #   2. Whether the box establishes a stacking context.
       #
       # Values have the following meanings:
       #    <integer>
       #       This integer is the stack level of the generated box in
       #       the current stacking context. The box also establishes a
       #       new stacking context.
       #    auto
       #       The stack level of the generated box in the current
       #       stacking context is '0'. The box does not establish a new
       #       stacking context.

Amendments 1a(ii) and 1b(i) together form my preferred approach since
I greatly dislike the "local stacking context" concept and propagation
construction (which is merely a vestige of CSS2): it
introduces cumbersome new terminology; it's easily replaced by a simpler
construction such as amendment 1a(ii); and it's confusing to say "in
which its stack level is '0'" because this isn't the stack level of the
stacking context itself but is instead merely a strange artificial
device to propagate the value '0' downwards to z-index:auto positioned
descendants.


Irrespective of whether you wish to pursue amendment 1b(i) to remove the
"local stacking context" concept, we must also consider the following
amendment to the definition of the 'auto' value of z-index:

1b(ii) In section 9.9.1 [1], 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.

since the root element always establishes a new local stacking context,
irrespective of whether it is positioned and what its z-index value is.
  Amendment 1b is necessary for correctness, but I guess I could live
without it.


Unrelated to the above, if we are prepared to accept amendment 1a, we
can also simplify item 6 in the list of painting layers:

1c. In section 9.9.1 [1], replace:
       # 6. positioned descendants with 'z-index: auto', and any
       #    descendant stacking contexts with 'z-index: 0'.
    with
       # 6. positioned descendants and stacking contexts with stack level
       #    '0'.

since this is more consistent with your proposed edits to the painting
layers text, and it allows the list of layers to focus on "stack level"
visual device instead of the underlying z-index machinery.  Amendment 1c
is "nice to have", rather than necessary.

===============================


Cheers,
Anton Prowse
http://dev.moonhenge.net

Received on Thursday, 15 April 2010 19:29:18 UTC