Re: [CSS21] stack level definitions in 9.9.1

Alan Gresley wrote:
> Justin Poirier wrote:
>> Anton Prowse wrote:
>>> Sylvain Galineau wrote:
>>>> Your proposal regarding auto and '0' is not included here. I 
>>>> found it
>>>> confusing as it could be read as conflicting with the description of 
>>>> layer 8
>>>> in Appendix E which does make a difference between auto/0 positioned
>>>> descendants.
>>>>
>>> Indeed, there /is/ a difference.  But that difference is not related to
>>> stack levels and painting layers, and hence there is no conflict.  (All
>>> such elements all lie on the same painting layer [#6 in the list] of
>>> whatever transpires to be their closest ancestor stacking context.)  The
>>> difference is in how the closest ancestor stacking context is 
>>> determined.
>>>
>> Sylvain, to complement what Anton is saying by rephrasing it: the 
>> difference
>> between auto and 0 descendants that you note in layer 8 of E regards how
>> they paint (or don't paint) THEIR descendants, and not which comes first
>> between the two in the current stacking context (ie. stack level).
>>
> 
> 
> Z-index auto and 0 are different if the painting order (source order) is 
> different. The below examples [...].

Your examples demonstrate precisely the opposite: they show that
z-index:auto and z-index:0 positioned elements of a common ancestor
stacking context do not get painted on different layers.  Rather, they
are treated identically and only document tree order decides the order
of painting on the layer.

This is why I wish to have positioned z-index:auto elements described as
having stack level '0'; without that, painting layer #6 is the "layer
for elements with stack level '0' and also for some other elements which
can be deduced as lying on stack level '0' via a somewhat odd
inheritance mechanism and also for some other elements whose stack level
is left undefined but which couldn't be negative (else they would lie on
painting layer #2) and which couldn't be positive (else they would lie
on painting layer #7)".  This situation isn't the end of the world, but
I think it's preferable to adopt something cleaner.

The seven painting layers in 9.9.1 in some sense encompass stack levels
(if one chooses to visualize stack levels as sub-layers).  Elements
with different stack levels may lie on the same painting layer; painting
layer #2, for example, consist of all elements with negative stack
levels, stacked in the order of most negative stack level first and then
document tree order second.  However, all elements with the same stack
level lie on the same painting layer.  Some layers don't contain any
elements which have a stack level, since they don't contain positioned
elements.  Really, the stack level concept is just a simplification (a
sort of subset) of the painting layer concept for positioned elements.
Chronologically, however, it arose the other way around: part of the
painting layer concept existed (albeit not carefully specified) in CSS1
(layers #1, #3, #4, #5, to be precise) and then other layers have been
slotted in for CSS2.1 which introduces the concept of positioning.


> If I have this:
> 
> <div>content</div>  <!-- painted lowest -->
> <div>content</div>
> <div>content</div>
> <div>content</div>
> <div>content</div>
> <div>content</div>
> <div>content</div>  <!-- painted highest -->
> 
> 
> Each div has a different painting layer. A negative top margin on each 
>  div would show this clearly.

You've lost me.  Obviously boxes are painted one atop the other rather
than blended together somehow.  (Later, the result of painting them
within their closest ancestor stacking context is then treated
atomically -- that is, painted as a single box -- at the appropriate
place within /its/ closest ancestor stacking context).  You're not using
"painting layer" in the correct sense in which it will be used in 9.9.1,
which is as a name for each of the items in the list of seven layers.


Cheers,
Anton Prowse
http://dev.moonhenge.net

Received on Sunday, 23 May 2010 23:17:21 UTC