- From: Bert Bos <bert@w3.org>
- Date: Fri, 4 Mar 2011 21:30:05 +0100
- To: "www-style@w3.org" <www-style@w3.org>
On Monday 14 February 2011 20:44:22 Anton Prowse wrote:
> On 11/02/2011 02:20, fantasai wrote:
> > === Mismatch A ===
> >
> > The proposal specified:
> > | 2. the stacking contexts of descendants with negative stack
> > | levels (most negative first).
> >
> > The current spec reads:
> > % 2. the child stacking contexts with negative stack levels (most
> > negative % first).
> >
> > The change is from
> > stacking contexts of descendants
> > to
> > child stacking contexts
> >
> > I am unsure whether this is a problem.
> >
> > The same change is present in mismatches C and D.
>
> Here, "child" is used with respect to the tree of stacking contexts.
> In some ways it's less sloppy than the proposed/old wording
> ("descendants", when what was really meant was "dependants" as
> defined in [1]; my proposal to fix that was rejected). However,
> given that the tree goes unstated, I think that the new wording is
> still not crystal clear.
The text may not define "child stacking context" directly, but it does
define "parent stacking context" and if there is a parent, there must a
child, isn't it? That's why I felt "child" more natural than your
"dependant."
But it is easy enough to define "child" (or dependant) explicitly, if
you think that helps. I'd put it after "Stacking contexts can contain
further stacking contexts."
>
> > === Mismatch B ===
> >
> > The proposal specified:
> > | 4. non-positioned floats.
> >
> > The current spec reads:
> > % 4. the floating descendants.
> >
> > This is most definitely an error. As Anton points out, it's a
> > regression of Issue 60a.
> > http://lists.w3.org/Archives/Public/www-style/2010Jul/0077.html
> > http://wiki.csswg.org/spec/css2.1#issue-60a
> >
> > This error is also present in Mismatch E.
>
> Agreed.
I added "non-positioned" back.
>
> > === Mismatch C ===
> >
> > The proposal specified:
> > | 6. positioned descendants and stacking contexts with stack level
> > | '0'.
> >
> > The current spec reads:
> > % 6. the child stacking contexts with stack level 0, and the
> > positioned % descendants with 'z-index: auto'.
> >
> > This change exhibits change A.
>
> As above.
Sometimes introducing an indirection can make things clearer, but in
this case "stack level 0" is confusing: it is equivalent to 'z-index:
auto' and is different from 'z-index: 0'. Nevertheless, I've replaced
"'z-index: auto'" with "stack level 0."
>
> > It also replaces
> > with stack level 0
> > with
> > with 'z-index: auto'
> > in the case of positioned descendants
>
> This is a purely editorial decision. However, I prefer our proposed
> wording (assuming the addition of the word "child" in line with the
> new approach). The raw 'z-index' property translates to the
> friendly "stack level" concept, and I see no need to re-introduce
> z-index into the list of painting layers, when the stack level
> concept can be used instead. There is value is separating the model
> from the delivery mechanism. Note that descendants (actually,
> dependants) with stack level 0 are precisely the stacking contexts
> with stack level 0 and the positioned descendants (dependants), and
> so the proposed sentence was correct and more concise.
As above: I put "stack level 0" instead.
>
> > === Mismatch D ===
> >
> > The proposal specified:
> > | 7. the stacking contexts of descendants with positive stack
> > | levels (least positive first).
> >
> > The current spec reads:
> > % 7. the child stacking contexts with positive stack levels (least
> > % positive first).
> >
> > This is an instance of change A.
>
> As above.
>
> > === Mismatch E ===
> >
> > The proposal specified:
> > | The contents of positioned elements with 'z-index: auto',
> > | 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.
> >
> > The current spec reads:
> > % Positioned elements with 'z-index: auto' (in layer 6),
> > % floats (layer 4), inline blocks (layer 5), and inline tables
> > % (layer 5), are painted as if those elements generated new
> > % stacking contexts, except that their positioned descendants
> > % and any child stacking contexts take part in the current
> > % stacking context.
> >
> > This mismatch exhibits several changes:
> >
> > 1. The change from
> > non-positioned floats
> > to
> > floats (layer 4)
> > is error B.
> >
> > This is definitely wrong.
>
> Agreed.
I added "non-positioned."
[...]
> 5. The last clause contains a change from
> any elements that actually create new stacking contexts
> to
> any child stacking contexts
>
> "child stacking contexts" is very misleading here; it's talking about
> closest descendant stacking contexts of <some types of element> but
> of course the <some types of element> don't actually form stacking
> contexts; they form pseudo–stacking contexts (which is of course the
> whole point of the paragraph). Hence these latter elements don't
> form part of the stacking context tree, and hence it's pretty much
> incorrect to talk about their "child" stacking contexts. Indeed,
> what the paragraph is trying to say is that these supposed "child"
> stacking contexts are children of the current stacking context [in
> the stacking context tree], and do not belong to the intervening
> "pseudo–stacking contexts". In other words, the paragraph is
> implicitly trying to reinforce the idea that "pseudo–stacking
> contexts" do not feature in the stacking context tree.
>
> I strongly feel that if Bert's approach is to be used then the
> stacking context tree needs to be made explicit, and that the
> misleading
>
> paragraph needs to be clarified. The latter might be achieved as
follows:
> | <ins>Within each stacking context, </ins>positioned elements
> | with 'z-index: auto' (in layer 6), floats (layer 4), inline
> | blocks (layer 5), and inline tables (layer 5), are painted as
> | if those elements <ins>themselves</ins> generated new stacking
> | contexts, except that their positioned descendants and any
> | <ins>would- be</ins> child stacking contexts take part in the
> | current stacking context.
>
> If those changes were to be made, I think I would prefer Bert's
> approach.
I added the three insertions.
>
> Either way, there's still some editorial work needed here.
>
> [1] http://dev.moonhenge.net/css21/spec/z-index/#descendant
For information, the full text is now:
For a positioned box, the 'z-index' property specifies:
1. The stack level of the box in the current stacking context.
2. Whether the box establishes a stacking context.
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 new
stacking context.
auto
The stack level of the generated box in the current stacking
context is 0. The box does not establish a new stacking context
unless it is the root element.
In this section, the expression "in front of" means closer to the
user as the user faces the screen.
In CSS 2.1, each box has a position in three dimensions. In addition
to their horizontal and vertical positions, boxes lie along a "z-
axis" and are formatted one on top of the other. Z-axis positions
are particularly relevant when boxes overlap visually. This section
discusses how boxes may be positioned along the z-axis.
The order in which the rendering tree is painted onto the canvas is
described in terms of stacking contexts. Stacking contexts can
contain further stacking contexts. A stacking context is atomic from
the point of view of its parent stacking context; boxes in other
stacking contexts may not come between any of its boxes.
Each box belongs to one stacking context. Each positioned box in a
given stacking context has an integer stack level, which is its
position on the z-axis relative other stack levels within 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 root element forms the root stacking context. Other stacking
contexts are generated by any positioned element (including
relatively positioned elements) having a computed value of 'z-index'
other than 'auto'. Stacking contexts are not necessarily related to
containing blocks. In future levels of CSS, other properties may
introduce stacking contexts, for example 'opacity' [CSS3COLOR].
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 child stacking contexts with negative stack levels (most
negative first).
3. the in-flow, non-inline-level, non-positioned descendants.
4. the non-positioned floats.
5. the in-flow, inline-level, non-positioned descendants, including
inline tables and inline blocks.
6. the child stacking contexts with stack level 0 and the
positioned descendants with stack level 0.
7. the child stacking contexts with positive stack levels (least
positive first).
Within each stacking context, positioned elements with stack level 0
(in layer 6), non-positioned floats (layer 4), inline blocks
(layer 5), and inline tables (layer 5), are painted as if those
elements themselves generated new stacking contexts, except that
their positioned descendants and any would-be child stacking
contexts take part in the current stacking context.
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.
Bert
--
Bert Bos ( W 3 C ) http://www.w3.org/
http://www.w3.org/people/bos W3C/ERCIM
bert@w3.org 2004 Rt des Lucioles / BP 93
+33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
Received on Friday, 4 March 2011 20:30:34 UTC