Re: [CSS21] stack level definitions in 9.9.1

Anton, I think you meant to introduce the following as a proposed
replacement in 9.9.1, not Appendix E :)

>
> 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.
>
>
Out of curiosity, why specify the layer in which inline blocks and inline
tables are painted, and not the same for z-index:auto elements and
non-positioned floats?

This passage inadvertently brought something to my attention. The phrase
"...any positioned elements and any elements that actually create new
stacking contexts..." also appears at various layers in Appendix E. At those
locations (I'm not sure about 9.9.1) it used to simply read "...any elements
that actually create a new stacking context..." This was true at least as
recently as April 2009. Could somebody kindly tell me when the additional
case of "positioned elements" was added to this sentence? I thought I'd been
following the stacking order issue fairly closely over the last couple
years, but I can't seem to find the point at which this change was made.

I think maybe this changes the meaning of what we're saying. By referring to
both positioned elements AND elements that create new stacking contexts,
unless we're being redundant, we intend a conjunction of 2 distinct
things... but the only positioned elements which don't create stacking
contexts are those with z-index:auto. So this must be what's meant by the
"positioned elements" expression. We already knew that elements which don't
create stacking contexts can't paint descendant elements that DO create
stacking contexts, instead passing them up to the nearest ancestor stacking
context... but this change adds that non-stacking-contexts can't paint
z-index:auto elements either! Note that z-index:auto elements, while unique,
are not elements which create stacking contexts.

This is significant because it adds a new type of element behaviour. In [a],
exclusively elements whose entire contents are painted by the Appendix E
algorithm were referred to as "stacking contexts", while other elements to
whose contents the algorithm might be applied in some form were referred to
as "stacking context-like elements". Stacking contexts paint descendant
stacking contexts as well as stacking context-like elements. Stacking
context-like elements only paint one another, leaving descendant stacking
contexts to be painted by the nearest ancestor stacking context.

According to the phrase at hand, z-index:auto elements are like stacking
contexts in that they get passed up by stacking context-like elements; yet
like stacking context-like elements in that they themselves pass the buck
when descendants turn out to be stacking-contexts or other z-index:auto
elements (one z-index:auto element can't paint another!).
Is this what is intended?
I apologize for how complex this sounds. I don't know of a non-complex way
to express it.
The issue is coming along, I think.

Justin Poirier
classroom306.com

[a] http://dev.moonhenge.net/css21/spec/z-index/