- From: Anton Prowse <prowse@moonhenge.net>
- Date: Sun, 28 Mar 2010 21:32:11 +0200
- To: Sylvain Galineau <sylvaing@microsoft.com>
- CC: "www-style@w3.org" <www-style@w3.org>
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
Received on Sunday, 28 March 2010 19:33:02 UTC