Re: [CSS21] stack level definitions in 9.9.1

I'm convinced by Anton's assertion that "stack level" is used to mean two
different things in 9.9.1, referring to both z-index value and the 7
painting layers.
I'd like to point out that the larger issues presented in Anton's paper[b]
regarding stacking contexts vs. stacking context-like elements, while they
may not be dealt with until a much later date (Maybe someone can update me.
An Oct 21 08 msg from Ian Hickson said they'd be kept in mind for CSS3...),
might make the present issue moot depending on how they're resolved. Anton
has suggested introducing the term "painting context" to refer to contexts
created for elements without an int z-index, and using the term "stacking
context" only for elements with an int z-index. Alternatively, he suggests
the respective terms "stacking context" and "strong stacking context".
Whatever the solution, I would propose we rethink our introduction to
painting order (9.9.1), starting with the complete removal of the list of 7
painting layers.
This list promotes a simplified and erroneous understanding of the topic. It
implies that a general solution to determining a page's painting order will
involve considering various-sized portions of the page (branches of the tree
of elements) one at a time, and applying an algorithm to each; with the only
overlap between portions being the fact that some are contained in others
(since the alg is recursive). This is not the case. As I tried to point out
in an article (http://classroom306.com/tutorials/z-index.html) that I wrote
and mentioned on this list a year ago, the steps in the alg that recursively
deal with descendants with int z-index are ONLY carried out in contexts that
THEMSELVES have int z-indices. This is why Anton made the distinction in his
paper between stacking contexts and stacking context-like elements. They are
both types of "portions of the page" to which the alg will be applied, but
they are different types and form different types of relationships in terms
of which ancestors paint which descendants. For example, Figure 1 in my
article shows 3 true stacking contexts which are painted as part of the root
stacking context, despite being separated from it by multiple generations of
stacking context-like elements. It should be clear that there is no general
way of telling which elements will be dealt with together based on their
proximity in the tree, as implied by having a "definitive" list of 7
painting layers. In reality page rendering can only be described as repeated
applications of the complex alg described in Appendix E, each acting on SOME
elements of the page. The only way of knowing which elements of the page
will be dealt with together is by understanding the alg. I understand that
it's a complex alg but I see no other way for a web designer to understand
painting order and not be confused by its behaviour for certain document
structures. Sugarcoating the concept with a list of painting layers doesn't
help. Maybe someone can offer another option.

Thanks,
Justin Poirier
classroom306.com

On Sun, Mar 28, 2010 at 3:32 PM, Anton Prowse <prowse@moonhenge.net> wrote:

> Sylvain Galineau wrote:
>
>> (The following aims to address issue 60 :
>> http://wiki.csswg.org/spec/css2.1#issue-60)
>>
>
> I've rearranged your email for the purposes of replying.  I hope this
> doesn't cause any confusion!
>
>
>
> 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.
>>
>
> This resolves part of [b: 2.10].  The remaining part (the addition of
> "non-positioned") has already been fixed, as you stated.
>
>
>
> 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).
>>
>
>  Changes in #2 and #3 are meant to precise and align 9.9.1 stacking
>> level descriptions with Appendix E's.
>>
>
> They succeed in that.  However, interestingly, you've distanced yourself
> from the term "stack level".  In doing so, we've gone from "stack level"
> being first defined as a façade for z-index yet later being used to
> encompass painting layers (see my discussion of 2.8, below), to now
> reducing its use as a façade for z-index.  This leaves us in the strange
> position of going to great lengths to introduce a term which is then
> barely used in the subsequent prose!  Aside from its definition, the
> only paragraph in which it would appear is:
>
>  # Each box belongs to one stacking context. 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.
>  # Boxes with greater stack levels are always formatted in front of
>  # boxes with lower stack levels. Boxes may have negative stack levels.
>  # Boxes with the same stack level in a stacking context are stacked
>  # back-to-front according to document tree order.
>
> The second and fifth sentences are incorrect, as I discuss in detail
> below in relation to [b: 2.8].  The third and fourth sentences could
> easily have "stack level" replaced by an explicit reference to z-index
> as you have done in your proposals (2) and (3) which we're currently
> discussing.  Indeed, rewriting the third sentence would remove the need
> for your changes to state "most negative first" and "1 first" which, to
> my mind, don't quite do the job of expressing the fact that the stacking
> occurs with strictly ascending z-index.
>
> So assuming that my argument for 2.8 below convinces you and the second
> and fifth sentences get corrected, there is no need whatsoever to
> preserve the term "stack level" and it can be omitted altogether from
> the spec.  (Note that in my proposed two rewordings, I was trying to
> cause as little disruption as possible to the concepts already
> introduced, and so I preserved the "stack level" concept and instead
> fixed the surrounding text to be consistent with it.  I'm actually
> happier to drop the "stack level" terminology altogether, and to go
> along the lines of your proposals here, instead.)
>
>
>
> 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.
>>
>
>  Change #4 gets rid of 'positioned' as a way to describe stacking
>> level as it seems inappropriate here
>>
>
> Agreed.  (Superfluous, rather than inappropriate; every stacking context
> arises from a positioned element (although the converse is false).)
>
>
>
> and reintroduces stacking level as a synonym for 'layer in the
>> painting order'.
>>
>
> The original sentence isn't really needed at all, since the algorithm
> which follows explicitly describes the stacking order.  (What's
> /actually/ needed there is a clarification that the stacking algorithm
> is recursive, which is implied but not currently explicit.)  I'm not
> sure what the value is in bringing the term "stacking level" (once, and
> only once) to Appendix E where it did not appear before.  Why is it
> needed in Appendix E which until now cared nothing for "stack levels",
> "stacking levels", "painting layers" etc?
>
>
>
> 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...
>>
>
>  Change #5 aims to be a more precise description of what follows.
>>
>
> I too prefer the use of the phrase "painting order" here.
>
>
>
> 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.
>>
>
> That's my take on the situation, too.
>
>
>
> 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.
>>
>
> I agree with this aim.
>
>
> As for the issues originally raised by Ingo Chao [a] and myself [b]:
>
>
> 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.
>>
>
> Indeed.  However, you haven't actually addressed the problem.  Even
> with your proposed changes, there remain places in the prose which use
> the term "stack level" to encompass the concept of "stacking
> level"/"painting layer", which leads to inaccuracies in the current
> wording of the spec.
>
>
>
> Then in Appendix E, the 'stacking level' term disappears and becomes
>> 'stacking order', under a paragraph heading of 'Painting order'.
>>
>
> "Stacking order" is a synonym for "painting order", and is not a
> conceptual part of the model but merely another way of saying "the order
> in which the elements are painted".  (The algorithm then describes that
> order, without reference to the /concepts/ of "stacking level"/"painting
> layer" and "stack level", both of which were introduced solely for the
> purposes of the "friendly description" of the model in 9.9.1.)
>
> I see no problem with these terms.
>
>
>
> Regarding [b], most of the issues raised are editorial
>>
>
> I do not recommend resolving the issues deemed editorial [...] 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.
>>
>
> I sympathize with those concerns.  However, I point out that all of the
> issues could be resolved without the introduction of new terminology.  I
> was careful to separate the analysis of the problems from the proposed
> rewordings, and the two rewordings I presented are merely one approach
> to patching up these editorial issues.  (Also, note that even if you
> were to choose one of the rewordings, only one of the first two terms
> you quoted is needed, depending on which proposal is chosen.)
>
> Moreover, many are editorial in the sense that 9.9.1. is ambiguous or
> even technically incorrect while they persist, rather than merely
> containing typos or clumsy language.
>
> I would like to see all these issues addressed, but it's certainly not a
> requirement that one of my proposed rewordings is used to achieve that.
>
>
>
> - Problem 2.1: the issue is editorial
>>
>
> Agreed.
>
>
>
> - Problem 2.2: the issue is editorial
>> - Problem 2.3: the issue is editorial
>> - Problem 2.4: the issue is editorial
>>
>
> These go hand-in-hand, and they are editorial in the sense that the
> reader is unlikely to make a wrong interpretation of what the spec
> currently says.  However, there's no doubt that the current wording is
> inaccurate.
>
>
> - Problem 2.5: the issue is editorial
>> - Problem 2.6: the issue is editorial
>>
>
> Agreed.
>
>
>
> - Problem 2.7: the issue is editorial
>>
>
> Agreed; however, the concept of "two stack levels" as currently exists
> in the spec is clumsy, needless, and unnecessarily complex.  It also
> itself introduces new terminology ("local stacking context") which is
> superfluous since it is unused outside of the definition of z-index.
>
>
>
> - 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.
>>
>
> My response is also 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.
>>
>
> It overlaps the original issue raised in [a] by Ingo Chao, but it's not
> quite the same and I disagree that either is fully addressed by your
> proposed changes.  Those changes help to reduce the intermingling of the
> terms "stack level" and "stacking level" raised in [a] and [b: 2.8], but
> they don't address the fact that these are still two different
> concepts in your proposals, with confusingly similar names (which is the
> subject of the current discussion, also raised in [a]).
>
> I agree that this issue, [b: 2.9], is editorial.  As I have mentioned
> above, we can  easily get rid of "stack level" altogether; and as I
> mention below, doing so would be one way of resolving problem 2.8.
>
>
> [ - Problem 2.10: addressed by change proposal (1) above. ]
>
>
>
> - 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]
>>
>
> Indeed, this is now fixed.
>
>
>
> 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.
>>
>
> [c.1] also brings up the following issue:
>
> 9.5 Floats currently states that the contents of floats are stacked as
> if floats generated new stacking contexts, except that any positioned
> elements and elements that actually create new stacking contexts take
> part in the float's parent stacking context.
>
> This information is not present in 9.9.1.  I suggest that this
> information be moved to or repeated in 9.9.1.
>
>
>  - The issue raised by the second testcase [c.2] is also addressed by
>>  Change #1.
>>
>
> Agreed.
>
>
>
> - The third testcase [c.3] is a testcase for problem 2.8 in [b].
>>
>
> (The citation [c.3] was incorrect; it should have been
>
> http://dev.moonhenge.net/css21/spec/z-index/testcases/stack-level-of-non-positioned-elements.html
> )
>
>
> 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.
>>
>
> Not so.  The test case -- which attempts to be of the first kind
> helpfully described by David: one that one part of the spec says should
>
> be displayed in one way and another part says should be displayed
> another way -- states that there is a *contradiction* in 9.9.1.
>
> On the one hand, 9.9.1 does indeed say that the painting order, from
> back to front, places non-positioned floats below non-positioned in-flow
> inline-level descendants.  (Note that this is what I intended to say in
> the final bullet-point in the description beneath the test case, but
> looking at it now it appears to have come out garbled. The intention is
> clear from the subsequent paragraph, however.)
>
> On the other hand, 9.9.1 also says that boxes with the same stack level
> in a stacking context are stacked back-to-front according to document
> tree order.  Now, we all know that the spec is really talking about one
> those seven listed painting layers in 9.9.1, and hence doesn't intend to
> introduce a contradiction because non-positioned floats are on a
> different layer than in-flow inlines and hence the statement about
> document tree order doesn't apply.  But that's the problem: it *doesn't*
> use the term "painting layer", or even the term "stacking level" that is
> used when introducing the seven layers (and which is never heard of
> again).  It uses the term "stack level" which is an imprecise concept
> introduced earlier in 9.9.1 based on z-index and not based on the seven
> listed layers.
>
> I point out that the test case isn't particularly useful here, but it
> was requested and I'm not sure what more one can do to attempt to
> demonstrate a logical contradiction arising from inconsistent
> definitions in the prose with a test case.  I suggest that the bullet
> points in the description of the test case, which present the logical
> steps to build up the contradiction, are rather more important than the
> test case itself.
>
> To summarize the issue: the definition of stack level is faulty.  The
> spec states that "each box in a given stacking context has an integer
> stack level", yet this is patently untrue.  A non-positioned in-flow
> inline doesn't (as currently specified) have a stack level, and
> certainly not one which is numeric, let alone integral.  What it *does*
> lie on is a "painting layer"/"stacking level" within the containing
> stacking context, and these layers are ordered according to the list.
> The term "stack level" as currently employed tries to encompass,
> unsuccessfully, both the concept of integer z-index and the concept of
> the seven painting layers within a stacking context.  Yet these are
> fundamentally different things.
>
>
> Further, it is unclear why a computed numeric value needs to be
>> assigned to the z-index property
>> for these elements
>>
>
> I didn't say that it did.  The z-index property is fine.  It's the
> "stack level" concept that's problematic.
>
>
> since a) the property only applies to positioned elements and b)
>> neither the span or float
>> in the testcase establish a stacking context.
>>
>
> Precisely!  The trouble is that the the term "stack level" is introduced
> as a friendly façade on the z-index concept, but which is then applied
> to boxes to which z-index doesn't apply: "Each box in a given stacking
> context has an integer stack level".  If we're going to insist on
> muddying the waters by allowing the "stack level" concept to encompass
> not only z-index but also the painting layers concept (which personally
> I disagree with, but which I incorporated into in my proposed rewordings
> to minimize the disruption to the existing prose) then we do at least
> need to ensure that it's internally consistent.  I introduced the extra
> computed numeric values *to "stack level"* because I was trying to
> preserve the existing phrase "Boxes with greater stack levels are always
> formatted in front of boxes with lower stack levels."  This only makes
> sense if stack levels for non-positioned boxes are (a) defined, (b)
> numeric and (c) different for the different painting layers in the list.
>
> Note that I could have reworded the problematic phrase to only apply to
> positioned elements (ie, only to elements to which the z-index property
> applies), and then it wouldn't be necessary to introduce new numeric
> values of "stack level".  But I was trying to be as faithful as possible
> to the existing wording.
>
> As I said above, to resolve this problem, I'd be equally if not more
> happy to remove the "stack level" concept altogether, and talk about
> either z-index/positioned elements or "stacking levels"/"painting
> layers" where appropriate; that is, to more carefully separate the two
> concepts.
>
>
>
> The painting order stacks described in 9.9.1 and Appendix E agree
>> on their proper position. All major browsers render this testcase
>> interoperably.
>>
>
> Indeed!  The test case states that the rendering shown is in accordance
> with Appendix E, and the list in 9.9.1 matches the Appendix E.  Its
> purpose is to describe the additional, contradictory rendering implied
> by the current text, as described above.  Again, I don't really see the
> value of a test case for analyzing this issue, but it was requested.
>
>
> So, to summarize my response:
>
> *) Your proposed changes partially solve test case [c.1] and fully solve
> test case [c.2] / issue [b: 2.10].
>
> *) The remainder of test case [c.1] can be solved by copying or moving a
> paragraph from 9.5 Floats to 9.9.1. where it is equally if not more
> relevant.  This partially solves editorial issue [b: 2.2].
>
> *) Test case [c.3] (corresponding to problem [b: 2.8] is not solved.
>
> *) Your proposed changes removes the dependency of the list of "stacking
> levels"/"painting layers" on the problematic concept of "stack level".
> In doing so, they help illustrate that there is little need for the
> concept of "stack level" in the first place.  It could easily be
> removed, and doing so would also solve problem [b: 2.8], fix the
> editorial clumsiness in [b: 2.7], and remove the potential for confusion
> described in [b: 2.9].
>
> *) I'm unconvinced by your proposed change (4), and rather think that if
> Appendix E needs modifying at all then it should be to clarify that the
> process of laying out stacking contexts is recursive.
>
> *) Regarding the remaining issues in [b] which you deem editorial, none
> requires new terminology to fix (although I chose to go down that route
> in my own suggested rewordings).  Also, several are more than merely
> scruffy, in the sense that 9.9.1. is ambiguous or even technically
> incorrect while they persist.
>
>
>
> [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
>>
> Should read:
>
> http://dev.moonhenge.net/css21/spec/z-index/testcases/stack-level-of-non-positioned-elements.html
>
>
> [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
>>
>
>
> Cheers,
> Anton Prowse
> http://dev.moonhenge.net
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>