Re: [CSS21] stack level definitions in 9.9.1

Sylvain Galineau wrote:
> 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 ***.

OK.  Note that the numbering of your new proposals has gone astray,
since #3 appears twice.  You've actually provided 6 proposals, not 5!



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

Great, as far as it goes.

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

Indeed, there /is/ a difference.  But that difference is not related to
stack levels and painting layers, and hence there is no conflict.  (All
such elements all lie on the same painting layer [#6 in the list] of
whatever transpires to be their closest ancestor stacking context.)  The
difference is in how the closest ancestor stacking context is determined.

[As we know, positioned children of a z-index:auto element "pass
through" to the ancestor stacking context; whereas for the positioned
children of a z-index:0 element, that element /is/ the ancestor stacking
context and hence they don't pass through it.  Thus a z-index:auto
element and its z-index:auto child are both treated as equals, within
their closest ancestor stacking context, despite their parent-child
relationship which only comes into play with the "document tree order"
thing.  Justin Poirier noted this with interest in [6].]


> 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 certainly don't think there's anything wrong with Appendix E (modulo
the proposal we agree on, below), and I don't see why there should be
confusion since Appendix E consciously doesn't discuss stack levels at
all,(*) which are a plaything of 9.9.1 introduced to try to make the
overview more accessible to authors.  Appendix E very carefully and
explicitly discusses each possible type of element, and of course says
that positioned descendants with z-index either 0 or auto all lie on the
same painting layer of their parent stacking context, which is merely
what my proposal for stack level '0' reflects anyway.  Stack level is
(now) just a way of describing in what order the various positioned
descendants in a given stacking context should be laid out, and those
with z-index either 0 or auto are interchangeable in this regard (but
not in other regards, as I've already mentioned).

(*) ...well, it didn't until your proposal for Appendix E (below) came
along, which I've turned a blind eye to since (a) your use of the term
there is meaningless, (b) it doesn't cause any harm, and (c) it becomes
meaningful if one assigns certain non-integral stack levels to
non-positioned elements as described in the proposals contained in my
original paper [5] although there is no purpose in doing so and no loss
in /not/ doing so.


> (I'd rather touch E as lightly as I can, personally).

Agreed.


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

But this is assuming that "stack level" == "z-index".  It isn't,
*precisely* in that z-index:auto lies on stack level '0'.  (It does,
even if we don't change the spec to say that out loud ;-).)  Stack level
is an (almost trivial) projection of z-index onto the integers.  The
very existence of the stack level concept in 9.9.1 seems to me to be
merely the result of an ancient editorial decision that "position on a
z-axis" was too scary for authors whereas "levels, rather like stacking
sheets of paper one atop the other" was not.  Possibly I even agree with
that.

Hence, there's no computed value concern here; z-index:auto computes to
whatever the spec currently says it computes to (which, in fact, it
fails to say; this should probably also be addressed).


> Overall, I didn't feel the issue warranted the risk of additional
> misunderstanding and thus extra caveats in what remains an overview.

I don't believe that extra caveats are necessary.  However, if you feel
that there is scope for misunderstanding, despite what I've argued here
and in previous posts, I don't think I can offer anything further to
counter that view.

I'll accept your decision, but I will note here for the record that the
failure to explicitly place z-index:auto positioned elements on stack
level '0' means that the stack level is not defined for such elements in
the case that they don't have a positioned ancestor with integer
z-index, as explained in my previous post.[3]  This does not introduce
any errors or inconsistencies, but it's clearly not ideal either.


> The overview will necessarily lack the precision of Appendix E. I am OK 
> with that.

OK.

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

Yet 9.9.1 will accurately reflect Appendix E irrespective of whether we
go with my "z-index:auto lies on stack level '0'" proposal, given the
the other proposals that we agree on.  The question here is simply
whether we care that a special case exists in 9.9.1 where our
non-normative author-facing stack level concept is not well defined.

OK. I shall leave it at that!



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

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

Thus we agree on part of my proposal #5 in [2], which I'm happy about,
of course!


However, you have rejected the other part of that proposal:

> *** 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
Justin Poirier wrote:
> Out of curiosity, why specify the layer in which inline blocks and
> inline tables are painted, and not the same for z-index:auto elements
> and non-positioned floats?

Because the layers for positioned elements with 'z-index: auto' and
non-positioned floats are clearly described in the list of seven
painting layers immediately preceding the paragraph under discussion,
whereas the layers for non-positioned inline blocks and non-positioned
inline tables are not.

Seemingly this is not as self-evident as I imagined, so feel free
to restate the layers (#6 and #4 respectively) for those former types in
this paragraph if desired or, alternatively, mention non-positioned
inline blocks and non-positioned inline tables directly in layer #5 in
the list and do without the last sentence of my proposal completely.


> and b) by the use of 
> 'such' could seem to conflate all four box types.

"such x" == "those x of the kind just described" => "non-positioned
inline blocks and non-positioned inline tables".

This expanded version of my shorthand could be used instead, if you
preferred.


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

Your argument does not concern non-positioned floats, and so there is no
reason to reject the inclusion of these from my proposed amendment.
Indeed, the spec already contains the analogous paragraph --
word-for-word the same as the one we're discussing apart from
s/floats/inline blocks and inline tables/ -- in 9.5.  All I'm
recommending is that we move or copy this information to the paragraph
we're discussing, for tidiness/completeness.

Next, if you don't amend the paragraph under discussion to cover
positioned elements with 'z-index: auto', then we are left in the
bizarre position of having Chapter 9 mention the "almost stacking
context" behaviour of floats, of inline tables, and of inline blocks,
but not of positioned elements with 'z-index: auto' (whose description
would be buried away in Appendix E).  Do you claim that /that/ is not
confusing?  I will say, however, that at least this would not be
incorrect; it would merely -- and seemingly arbitrarily -- lack
preciseness, thus creating an obvious "gotcha" in Chapter 9, as indeed
is already the case.

As for the z-index:auto/z-index:0 thing, even if one accepts that there
is confusion (which I don't), I don't see that that issue has anything
to do with my proposed amendment to the paragraph under discussion.  My
amendment merely takes two pieces of information that are already
available in the spec (namely behaviour of floats from 9.5, and
behaviour of positioned elements with 'z-index: auto' from Appendix E)
and copies that information *word for word* to a more central place for
the sake of tidiness/completeness.

I hope you will reconsider your decision here, and recommend my
amendment in full!


> Lastly, this change affects 9.9.1, not Appendix E. ***
Justin Poirier wrote:
> Anton, I think you meant to introduce the following as a proposed
> replacement in 9.9.1, not Appendix E :)

Indeed.



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

Great :-)



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

Indeed :-)



On a final note, I keep noticing things that were in the proposals in my
original paper[a] that were not called out very loudly and hence were
overlooked. This time, it's the wording of painting layers #3 and #5 in
the list (using your latest proposal as the basis, rather than the
current spec, but the distinction is irrelevant to the point in question):

   # 3.in-flow non-inline-level non-positioned descendants.
   # 4.non-positioned floats.
   # 5.in-flow inline-level non-positioned descendants.

By descendants we mean boxes, not elements, right?  Else in the
following situation:
<p>
   <span style="float:left; height:10px; width:10px; margin-right:-10px">
   </span>
   lorem ipsum dolor sit amet
</p>
the lorem ipsum text (which isn't wrapped in an inline element) isn't
covered by the description of layer #5, yet we know it should be.
(Appendix E gets this correct, as usual.)

I'm not sure this is important enough to justify another amendment, but
it's something for you to bear in mind.



> 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 understand your position.

I strongly hope you'll reconsider your decision on the second part of my
proposal #5 in [2], and I vainly hope you might do so on the "stack
level '0'" thing which is my proposals #1a and #1b in [2] ;-)  However,
even if not, the six proposals you presented in your latest post amount
to a real and substantial improvement of 9.9.1; in particular, they
remove the internal inconsistencies and errors, which is the most
important outcome here.  Thanks once again for your perseverance and
patience!


> [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
   [6] http://lists.w3.org/Archives/Public/www-style/2010May/0243.html

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

Received on Wednesday, 19 May 2010 23:57:41 UTC