- From: Anton Prowse <prowse@moonhenge.net>
- Date: Mon, 12 Apr 2010 21:33:47 +0200
- To: Sylvain Galineau <sylvaing@microsoft.com>
- CC: "www-style@w3.org" <www-style@w3.org>
Hi Silvain,
I'm happy with the direction of your latest proposal, and we're very
close to agreement on this issue, despite what the length of this reply
might suggest!
Sylvain Galineau wrote:
> It is worth repeating that in the absence of testcases demonstrating interoperability
> issues I intend to keep editing changes to a reasonable minimum.
I understand and accept your point of view. (I do not believe that
there /are/ any interoperability problems, at least not as a result of
9.9.1. I don't believe for a moment that implementors use 9.9.1 at all;
rather, they use Appendix E, which I have no conceptual issues with.)
> This also will be
> my last attempt at coming to a resolution on the full set of issues you have reported.
> If we are unable to find agreement then I will recommend to the WG that we fix the
> one clear prose error (the 'floats and their contents' in 9.9.1's painting layer 4) and
> leave the rest of the prose unchanged. If the CSS2.1 prose is too hard to fix without
> a more extensive rewrite then I am personally much more comfortable attempting such
> a rewrite in a Level 3 module rather than risking the introduction of contradiction(s)
> between CSS2.1 and existing implementations.
Firstly, I'm enthusiastic about your latest proposal. Given the
constraints that you have laid down, I think it approaches the problem
in the right way. We will certainly find agreement -- in fact, I would
accept it without further modifications in preference to keeping the
existing text! Hence I very much hope you will not need to restrict
your recommendation to just the "floats and their contents" issue.
Secondly, I recognize that you would like to close this issue soon. But
I hope you will permit me to submit just a few more amendments to your
latest proposal, which I have produced within the spirit of your
constraints. Given the direction from which you've approached the stack
level problem, I believe that the CSS21 prose can be fixed without
extensive rewrites. Indeed, your latest proposal already goes a
significant way towards this, and I believe that my amendments leave us
with a logically watertight 9.9.1, which is my only aim here. (Of
course, I'd love to see the purely editorial issues addressed in a
future CSS module!)
> This being said, I certainly agree that this relatively complex area deserves improvement
> and your considerable efforts are very much appreciated. Thus, the shortcomings of my
> response as well as any inability to find consensus are mine only.
Thanks for the sentiment; for my part, I appreciate your efforts in
tackling this issue and seeking feedback.
> Now, some general comments:
> - I will not attempt to resolve the stack level vs. z-index terminology issue. I do not
> consider 'stack level' to be burdensome or defined at 'great lengths', nor do I consider its
> usage frequency to be relevant to the overall issue. Given that the term does exist, as
> well as a goal of minimal editorial changes, I am, however, interested in eliminating
> possible confusion as to its meaning.
I'm happy to accept your decision here, not least because your latest
proposal succeeds in eliminating the confusion surrounding the stack
level concept.
> - Your point about 9.5., floats and their in-flow inline content is, in my opinion, implicitly
> addressed by the high-level overview of painting layers in 9.9.1. (in-flow inline-level
> non-positioned *descendants* are just that; if the meaning of descendant is not clear at
> this stage of the spec, we have a much bigger problem than fixing this section)
I'm afraid you've momentarily lost me here! The only point I raised
about 9.5 Floats in my previous post[a] was that an important
description of their stacking behaviour is provided in 9.5 Floats but
that I felt this description should be copied or moved to 9.9.1. I have
no issue with the wording of that description. (More on this at the end
of my reply.)
If you're referring to my statement (unrelated to floats) that a
non-positioned in-flow inline doesn't (as currently specified) have a
stack level, I maintain that this is the case. However, this issue is
successfully resolved (obsoleted) in your latest proposal in which you
restrict the "stack level" concept to positioned elements.
If you're referring to my issues [b:2.2–2.4] (again unrelated to floats)
concerning the failure to define which stacking context a box belongs to
and the sloppy use of the terms "parent" and "descendant", I agreed in
my last post that these were editorial issues. I haven't checked, but I
wouldn't be surprised if similar problems do indeed exist elsewhere in
the spec, as you (almost) pointed out ;-). These editorial issues are
not blockers as far as I am concerned.
Now to the proposals.
> 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.
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 simply state that 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. 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 parent's box, or '0'
# if it or its parent is the root element. [...]
Note that unfortunately this amendment to the definition of the 'auto'
value perpetuates the conceptual blurring of "box" and "element" found
throughout the CSS21 specification.
If we are prepared to accept amendment 1a (and I think we do have to
accept some such amendment), we are free to remove the awkward "local
stacking context" concept and the propagation construction _without the
need for further tweaks_: we merely remove the two sentences concerning
"local stacking context" from the definition of z-index! This doesn't
lose us anything, since the fact that (only) positioned boxes with
integer z-index form stacking contexts is explicitly expressed lower in
the prose. (I dislike the "local stacking context" concept: it
introduces cumbersome new terminology; it's easily replaced by a simpler
construction such as amendment 1a; 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.) Please let me know how you feel about removing the "local
stacking context" concept; I shall refer to this removal proposal as
"amendment 1b(i)".
On the other hand, if you wish to preserve 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.
Regarding your latest proposal[d] for list of painting layers, it
resolves [b: 2.9], and I'm delighted by your proposed changes to the
intro and outro paragraphs, especially the explicit mention of the
recursive nature of the model and the normative nature of Appendix E.
I'm largely in favour of your minor edits to the description of the
painting layers, although I've got a couple of minor amendments which
are based on your first proposal[e] and which I hope you will find
acceptable. Below, I began by quoting your latest proposal verbatim but
then amended it /in situ/ with my changes; following that, I precisely
describe these amendments:
2. 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.
My amendments, contained in the above, are as follows:
(i) The addition of "(most negative first)" to the second item in the
list of layers;
(ii) The restoration of "the stacking contexts of" to the seventh item
in the list of layers, and the removal of your proposed "positioned" there;
(iii) The addition of "(least positive first)" to the seventh item in
the list of layers;
(iv) The removal of your proposed "in document tree order" from the
first sentence of the outro paragraph.
Amendments (i) and (iii) give us the best of your two proposals [d,e]
reinforcing the message given higher up the prose that stacking contexts
are stacked in z-index order.
Amendment (ii) is given by analogy with the second item in your
proposal, and also appears in the existing spec; I think the phrase "the
stacking contexts of" serves the useful purpose of reinforcing the
recursion idea. (I suspect you didn't really mean to remove it!)
Amendment (iv) is given because I didn't quite understand the purpose of
the "in document tree order" phrase here, nor am I convinced that it's
even correct in this position. The fact that (positioned) boxes with
the same stack level are stacked in document tree order is already
stated higher up in 9.9.1 (and preserved in your latest proposal, which
I agree with). The fact that non-positioned boxes on the same painting
layer are stacked in document tree order is not captured by your
proposals, but I don't think that the addition of the phrase to the
outro paragraph succeeds in expressing this fact. The difficulty arises
because painting layers 2 and 7 bundle stacking contexts at different
stack levels together, and so these two layers are laid out with respect
to stack level first and document tree order second, whereas the other
layers are merely laid out with respect to document tree order. I don't
see a simple and elegant way of expressing this difference in the prose,
and so I'm actually happy to leave it unhighlighted in 9.9.1. This
would mean that 9.9.1 omits an important detail, but (a) the reader will
probably infer it by analogy with the stated situation for (positioned)
boxes with the same stack level, and (b) it's common sense, and (c) it's
clear from the normative Appendix E.
Regarding Appendix E, I'm happy with your two proposals below.
> 3. 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 stack level of all the other elements in the stacking
> # context is then resolved at rendering time using the painting
> # order below.
> 4. 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...
Finally, I'd like to return to the issue I raised in my previous
post,[a] concerning 9.5 Floats and the description of stacking behaviour
described therein. I still suggest that this be moved or copied to
9.9.1 to the paragraph which describes the same behaviour -- that of
"painting contexts", in one of my original proposals[c] -- exhibited by
inline blocks and inline tables.
Moreover, I now realize that I forgot to express another point in my
previous post: Appendix E explicitly states that positioned elements
with z-index:auto also exhibit this behaviour,[2:E.2, step 8] but this
is not expressed anywhere in the current text of 9.9.1, nor in your
proposals. (It doesn't appear in my original list of issues[b] since it
is subsumed into other issues in that list. It does however appear in
both my original change proposals for 9.9.1.)
Accordingly, I propose the following change.
5. In Appendix E, E.2 [2], replace:
# The contents of inline blocks and inline tables are stacked as
# if they generated new stacking contexts, except that any
# positioned elements and any elements that actually create new
# stacking contexts take part in the parent stacking context. They
# are then painted atomically in the inline stacking level.
with
# The contents of positioned elements with 'z-index: auto', and
# non-positioned floats, inline blocks and inline tables are
# stacked as if they generated new stacking contexts, except that
# any positioned elements and any elements that actually create
# new stacking contexts take part in the parent stacking context.
# Such inline blocks and inline tables are painted atomically in
# layer 5.
The amendments here consist of including floats and positioned
z-index:auto elements, restricting the discussion to /non-positioned/
floats and inlines (which is an omission in the current text), and
avoiding the phrase "stacking level" (which slipped through your
latest proposal!).
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,1a,2,3,4,5, and either 1b(i)
or 1b(ii), and also preferably 1c, exactly as written here in this post,
are what I submit for consideration.
[a] http://lists.w3.org/Archives/Public/www-style/2010Mar/0470.html
[b] http://dev.moonhenge.net/css21/spec/z-index/
[c] http://dev.moonhenge.net/css21/spec/z-index/css21_zindex_proposal1.html
[d] http://lists.w3.org/Archives/Public/www-style/2010Apr/0013.html
[e] http://lists.w3.org/Archives/Public/www-style/2010Mar/0417.html
[1] http://www.w3.org/TR/CSS21/visuren.html#z-index
[2] http://www.w3.org/TR/CSS21/zindex.html
Cheers,
Anton Prowse
http://dev.moonhenge.net
Received on Monday, 12 April 2010 19:34:47 UTC