W3C home > Mailing lists > Public > www-style@w3.org > October 2008

Re: [CSS21] stack level definitions in 9.9.1

From: Anton Prowse <prowse@moonhenge.net>
Date: Wed, 22 Oct 2008 21:39:30 +0200
Message-ID: <48FF8172.3080704@moonhenge.net>
To: Ian Hickson <ian@hixie.ch>
CC: www-style@w3.org

 > On Tue, 20 May 2008, Anton Prowse wrote:
 >> http://dev.moonhenge.net/css21/spec/z-index/ .  The paper presents
 >> several proposals for the clarification of the relevant sections of
 >> the specification.

Ian Hickson replied:
 > the author prefers a different kind of wording to the wording in
 > the spec

I am emphatically in favour of a wording (any wording, not necessarily 
my own) which is intelligible over one which is nonsensical.  Presumably 
this is not in itself a controversial stance.

 > By and large I would recommend rejecting editorial changes, on the
 > principle that making editorial changes is risky (it can lead to
 > unintentional normative changes).

This is a valid concern, although see my comment below.

 > This paper appears to contain a series of editorial disagreements[...]

 > It is possible that this paper contains reports of errors that I
 > misunderstood to be mere editorial requests.

I don't really follow the binary division you make between errors and 
editorial requests in this case.

Sections 2.1--2.3 in the paper are editorial requests but highlight 
ambiguities in 9.9.1.

Section 2.4 highlights a reoccurring wording which is erroneous in 
9.9.1.  [Example: according to the spec, stacking layer 2 of a given 
stacking context C consists of "the stacking contexts of descendants 
with negative stack levels".  However, this is clearly not intended to 
catch /all/ descendants with negative stack levels, only those for whom 
C is the containing stacking context.]

Sections 2.5--2.7 and 2.9 are purely editorial.  (That is, they contain 
no changes to the presented logic.)

Section 2.8 highlights the knottiest problem with the current spec, 
which also direct affect the wording of the definition of the z-index 
property.

The spec says: "The stack level of an element in the current stacking 
context whose value of z-index is ‘auto’ is the same as its parent’s 
box."; and also: "Boxes with the same stack level in a stacking context 
are stacked back-to-front according to document tree order."

Yet this would imply that, within a stacking context S that contains an 
in-flow inline-level child E followed by a non-positioned floated child 
F (both of which have z-index:0) E and F should be stacked according to 
document tree order.  That is nonsense: in fact E is stacked on top of F 
according to the stacking levels listed later in 9.9.1.

 > I would request that any such errors be documented in the form of a
 > simple HTML document showing a precise case that is ambiguous
 > according to the spec, or showing a precise case that the spec defines
 > to have a rendering that disagrees with the majority of Web browsers.
 >
 > Such HTML files would significantly help the working group to
 > determine the importance of the errors.

I fail to see how test cases can shed any more light on the issues here. 
  However, it may be that this indicates how you conceive of a mutually 
exclusive division between an error and an editorial request: the former 
being a flaw revealed through practical demonstration, with the latter 
being one revealed through logical examination?  I would usually take an 
"editorial request" to mean one which merely demonstrates typos or other 
accidental mistakes, or which proposes a reordering which does not alter 
the logic of the passage in question.

 > making editorial changes [...] can lead to unintentional normative
 > changes

Yet much of 9.9.1 merely attempts to be a (rather incomplete) summary of 
the stacking algorithm in Appendix E, and hence should not be normative 
in any case.  (Whilst I am in favour of a /non-normative/ summary within 
9.9.1, it seems somewhat dangerous to attempt to create two different, 
/normative/ versions of the same rather complex algorithm.)

Given the bewilderment already expressed by a number of people here on 
this mailing list towards the current wording of 9.9.1, would it not be 
better to simply remove most of 9.9.1 and point the reader to Appendix E 
instead?  (Apparently you suggested this yourself at some point [1].) 
Aside from the non-normative motivational text and the definition of 
z-index, 9.9.1 provides nothing new and so in my opinion it would be 
better to remove the problematic parts than keep them in their current form.

[1] http://lists.w3.org/Archives/Public/www-style/2008Jul/0312.html (at 
the very bottom of the correspondence, in the quoted section by Ingo 
Chao;  I cannot locate the earlier email on the archives.)

Cheers,

Anton Prowse
http://dev.moonhenge.net
Received on Wednesday, 22 October 2008 19:40:23 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:55:15 GMT