Re: [CSS21] stack level definitions in 9.9.1

Ingo Chao's concerns are valid, as are those of expressed
(http://lists.w3.org/Archives/Public/www-style/2006Oct/0017.html) by
Roger Olsson in 2006.  In response to the latter, Mike Bremford stated
(http://lists.w3.org/Archives/Public/www-style/2006Oct/0018.html) that
9.9.1 is "confusing, poorly worded, and correct."  Alas only the first
two adjectives hold.

There are (at least) eight ambiguities or errors in description in 9.9.1
of stacking contexts, stacking levels and z-index (which is one of the
more complex parts of CSS 2.1 and which presents rather more editorial
difficulties than other areas of the specification).

Due to the number of problems involved, I have taken the unusual step of
presenting and analysing them in a separate paper rather than treating
them here on this mailing list:
http://dev.moonhenge.net/css21/spec/z-index/ .  The paper presents
several proposals for the clarification of the relevant sections of the
specification.  In summary, the issues addressed are:

* failure to define a term to describe the stacking context–like
behaviour displayed by floats, inline-blocks, inline-tables and
positioned, z-index:auto elements;
* failure to specify the stacking context in which a box participates;
* questionable use of the term "parent stacking context";
* use of the term "descendant" where something more precise is intended;
* reference to the global z-axis when a series of local z-axes would
provide a readier description of the model;
* ambiguity in the definition of atomicity of stacking contexts;
* over-complication arising through the concept of a stacking context
having two stack levels;
* unspecified "stack level" of non-positioned elements;
* ambiguity arising from the undefined term "stacking level", and 
confusion arising from its similarity to the term "stack level" and the 
use of Arabic numerals to label such stacking levels.

A separate issue not discussed in the paper is that 9.9.1 claims to list 
the stacking levels which make up a stacking contexts, only to say 
afterwards that Appendix E contains a more thorough list; indeed, the 
first list is not exhaustive of course, and so should not be normative. 
  It should be made clearer that it is merely a summary of the most 
important behaviour.

Comments are invited on this mailing list.


Thanks,

Anton Prowse
http://dev.moonhenge.net


 > In Appendix E, there is not much room for a "stacking level" of an
 > element, because an element is deconstructed into its background and
 > inline box. Any defined integer "stacking level" that is set by
 > z-index could come into play for E2.3., E2.8., and E2.9. only, but not
 > for the other steps in the painting order. Therefore, the term
 > "stacking level" could mean the z-order of the positioned elements,
 > and is not clearly defined in E2.1., E2.4.-E2.7., and E2.10. It is not
 > easy to explain E2.6.+E2.7. when thinking in "levels."
 >
 > z-index rules the painting order of positioned elements and lets them
 > establish new atomic stacking contexts. Appendix E2.1.-2.10. is a
 > procedural description of positions in the painting order.
 >
 > Because the z-index value integer is defined in 9.9.1 as: "This
 > integer *is* the stack level of the generated box in the current
 > stacking context", the term "stack level" cannot be easily seen
 > without being linked to z-index, but z-index does apply to positioned
 > elements only, and this conflicts with 9.9.1: " *Each* box has an
 > integer stack level, which is its position on the z-axis relative to
 > other boxes in the same stacking context."
 >
 > 9.9.1 says "Each stacking context consists of the following stacking
 > levels (from back to front): ... [1.-7.]", but you cannot map this
 > 1.-7. with Appendix E2.1-2.10. Following the link to the more thorough
 > explanation of the stacking order in Appendix E, there is no mention
 > of "stack level" or "stacking level" anymore. This does not work for
 > me.
 >
 > To me, there doesn't seem to be a need for a static term "stacking
 > level", since it doesn't help me in understanding the CSS-concept of
 > "stacking"; it rules the interaction of positioned elements only, but
 > that doesn't add anything to the meaning of the term "z-index". For
 > any element and its deconstruction, the procedural term "positions in
 > the painting order" may be more appropriate, in the context of
 > Appendix E.
 >
 > But this may have its origin in my German language, since whenever
 > "level"/"Ebene" is added to any complex term, suddenly it becomes
 > unclear. Sorry if I am misinterpreting 9.9.1 in conjunction with
 > Appendix E.
 >
 > Thanks
 >
 > Ingo
 >
 > http://www.satzansatz.de/

Received on Tuesday, 20 May 2008 17:18:32 UTC