W3C home > Mailing lists > Public > www-style@w3.org > November 2010

Re: [CSS21] zindex.html E.2 issue: ordering contradictions

From: Anton Prowse <prowse@moonhenge.net>
Date: Sun, 07 Nov 2010 10:22:58 +0100
Message-ID: <4CD66FF2.8000103@moonhenge.net>
To: www-style@w3.org
CC: Peter Moulder <peter.moulder@monash.edu>
On 05/11/2010 04:28, Peter Moulder wrote:

> If I understand correctly, zindex.html as currently written includes some
> items (say the background image of element X) more than once: various
> places in the list include "all [qualifier] descendents [of E]", which
> typically includes descendents of some different E that's also included in
> the painting order.

I believe that the issues you're raising in your post are a subset of 
those I raised at the start of my campaign to get 9.9.1 changed.[1]  The 
"soft" ones (such as the use of the term "descendant" when something 
more precise is intended) were rejected for CSS21, and it's very 
unlikely that this will be reopened.  (Important changes were approved 
for 9.9.1 however, as can now be seen in the Editor's Draft.)

> For example, item 5 with respect to the root element consists of
> "[a]ll non-positioned floating descendants, in tree order", followed by a
> sentence which (by my understanding) explains that inclusion of a floating
> descendant should be considered equivalent to expanding this big list with
> respect to that floating descendant, but excluding [the expanded painting
> order of] "any positioned descendants and descendants which actually create
> a new stacking context".

Your understanding seems correct there.

> One issue is that it isn't clear that that is what the text means;

E2 is not a full description of the painting model.  Rather, E2 is to be 
used in place of the seven-item list in 9.9.1.  The rest of 9.9.1, 
together with E2, forms the normative description of the model.

In particular, 9.9.1 states:

   # 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.

and:

   # This painting order is applied recursively to each stacking context.

and:

   # Each box belongs to one stacking context.

What we're really doing when compositing the document is determining the 
dependants of each stacking context and pseudo–stacking context (terms 
which I defined in my original proposals (see [1])), and then, working 
upwards from the innermost (pseudo–)stacking context, compositing said 
context according to the rules of E2 and treating any already-composited 
context as atomic.

There is no "double treatment" of any box.

> while
> the other is that (under this interpretation) it doesn't exclude inline
> blocks or non-positioned floating descendants, so non-positioned floating
> descendants of those inline blocks or non-positioned floating descendants
> would be included first in item 5 with respect to that inline block or
> floating descendant, and then included again in item 5 with respect to the
> root element.

Not so, because inline blocks and non-positioned floats form what I call 
pseudo–stacking contexts [see the sentence that you referred to], and 
hence are treated atomically.  The "descendants" that the spec is 
interested in are those for whom the current (pseudo–)stacking context 
is their "containing" (pseudo–)stacking context.  A non-positioned float 
within a non-positioned inline block within a non-positioned float is 
not up for consideration as a descendant of the outer float since its 
containing pseudo–stacking context is the inline block not the outer float.

[1] http://lists.w3.org/Archives/Public/www-style/2008May/0243.html
(Note that the conversation spans several months (years!) yet the "Next 
in thread" functionality of the mailing list software is limited to one 
single month.  To follow the full conversation, I recommend searching 
the mailing list for the thread title.)

Cheers,
Anton Prowse
http://dev.moonhenge.net
Received on Sunday, 7 November 2010 09:24:26 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:34 GMT