Re: [CSS21] stack level definitions in 9.9.1

A correction to my last email: I listed "options I see" as 'a', 'b' and '3'!
Obviously I meant 'c', not '3'.
Justin

On Thu, Apr 1, 2010 at 7:50 PM, Justin Poirier <poirier.justin@gmail.com>wrote:

> My point was that the abbreviated version was not a correct one.
> My problems with it are:
> 1) It is a static ordering of types of elements; which, the reader might
> assume, is to be thought of at various levels of specificity (e.g. as
> applying to the entire page from root down, or to some other element and its
> descendants). This is not the complete picture of how a page's painting
> order is determined.
> 2) It is incorrect. By now we've proven "stacking context" can mean 2
> different things; in cases where it means stacking-context-like elements,
> painting levels 2, 6 and 7 won't exist! Options I see: a) add a clause to
> each of 2, 6 and 7 saying they only exist in stacking contexts with int
> z-index, b) have two lists of painting layers, one for stacking contexts and
> one for stacking context-like elements, or 3) get rid of this list as I
> suggested in my last email.
> Not that it's the issue at hand, but in defence of my article: it has both
> the alg from Appendix E in the left column, and my commentary in the right
> column which you only have to read if seeking explanation of the appendix.
> While writing it, I was conscious of it growing more and more complex, but I
> let that happen without limit because it needs to be brought to people's
> attention, how complex this part of the spec is.
>
> Justin Poirier
> classroom306.com
>
> On Thu, Apr 1, 2010 at 2:03 PM, Perry Smith <pedzsan@gmail.com> wrote:
>
>>     My two cents: I find Justin's page more confusing than Appendix E and
>> the Appendix more confusing than the abbreviated version.
>>
>> I do not see "in-flow" defined.  It crops up 30 times in the spec but I
>> can't find it defined.
>>
>> I also don't see how using sentence fragments helps.  For example, in the
>> detailed page, instead of:
>>
>> "1. background color of element over the entire canvas"
>>
>> I would have:
>>
>> "1. Paint the background color ...."
>>
>> Or better yet:
>>
>> "1. The background color is painted over the entire canvas".
>>
>> I think leaving out "by the UA" is ok.  For me, my brain simply stops when
>> I see sentence fragments.  And when I'm trying to understand something
>> really complex, a stopped brain is not much help :-)
>>
>> Try not to use "its" or "element" by themselves.  Frequently, a term like
>> "parent", "ancestor", "child", or "descendant" (or perhaps "parent element",
>> etc) would clarify the sentences greatly.  In both of the verbose texts, I
>> have to reread each sentence many times to try and parse out which "element"
>> or which "it" is being referred to.
>>
>> Calling the descendants "context" is not good at all.  "context" connotes
>> "outside" not "inside".  e.g. "in what 'context' did he say that?"
>>
>> On the flip side, the algorithm could probably be best expressed without
>> text at all.  Put it into a pseudo-code format but have pointers to where
>> each attribute (like "in-flow") is precisely defined.  The pseudo-code
>> format with variables would very clearly define the "it" and "element".  The
>> recursive nature would be much clearer.  I do not believe that the typical
>> non-programmer could grok any of the three versions in their current state
>> anyway.  So, at least please the programmers in the audience.
>>
>> Last I would use the policy, "if it looks like a technical term, then link
>> it to its definition" -- especially the first place it is used within a
>> section.  Since this is a web page (usually), the definitions could be done
>> with pop ups.  As a last resort, at least give me a place, a "Concept index"
>> or a "Glossary", that I can go to to find various terms.
>>
>> Hope this helps,
>> Perry
>>
>> On Mar 31, 2010, at 10:30 PM, Justin Poirier wrote:
>>
>>  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<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<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
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>