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

Re: [CSS21] stack level definitions in 9.9.1

From: Anton Prowse <prowse@moonhenge.net>
Date: Mon, 14 Jul 2008 22:44:52 +0200
Message-ID: <487BBAC4.4050505@moonhenge.net>
To: www-style@w3.org
CC: ichaocssd@googlemail.com, fantasai@inkedblade.net

 >>> Ingo Chao wrote:
 >>>> Can you add the issues
 >>>> http://lists.w3.org/Archives/Public/www-style/2008Jan/0057.html
 >>>> to the record? I did not get an answer from Hixie that would change my
 >>>> concerns, and they are not listed in Anton's paper.

 >>>> 2008/7/3 fantasai <fantasai.lists@inkedblade.net>:
 >>> I think the issue you raise there is covered by
 >>>  http://dev.moonhenge.net/css21/spec/z-index/#stacking-layer

Ingo's concerns are indeed addressed by resolving (several of) the 
issues raised in [1], for example by using the proposal presented in 
[2].  These particular concerns (which closely match the ones that I had 
before I resorted to deconstructing this part of the specification in 
order to make sense of it) arise from the conceptual mix-up contained in 
9.9.1 between "stack level" and "stacking level".

I maintain that a good way to untangle this mix-up is to forget about 
"stacking level" initially, and to explicitly define the numerical 
"stack level" for each box: via z-index for boxes corresponding to the 
contexts generated by positioned elements, and by manually assigning, in 
9.9.1, a stack level for all other types of boxes.  (In [2] for example, 
the box consisting of the background and borders of the element forming 
a context is defined to have stack level 'minus infinity' within that 
context, while the background+borders of its in-flow non-positioned 
non-replaced block-level dependants are defined to have stack level -0.8 
within that context, and its in-flow non-positioned block-level replaced 
dependants and its in-flow non-positioned inline-level dependants are 
defined to have stack level -0.2 within that context.)

Using this approach, it really is true that boxes with greater stack 
level are rendered "on top of" boxes with lower stack level, and that 
when we say that "boxes with the same stack level are rendered in 
document tree order" we actually end up with what we really wanted (and 
what is currently implemented by most browsers).

Recall that, as Hixie explained to Ingo, the only thing that the second 
half of 9.9.1 concerning "stacking levels" is trying to do (in a 
non-normative way) is to summarize the algorithm in Appendix E as a 
readily-understood model of layering order within a given stacking 
context.  (This is a laudible aim; web authors would surely prefer an 
at-a-glance list than a long algorithm.)

The easiest way to achieve this was to think of a given stack level 
within a given context as corresponding to a "painting layer" --- a 
transparent plastic sheet, if you will --- so that all boxes with that 
stack level in that context are painted on that flat sheet in document 
order.  These sheets are then composited (from lowest to highest stack 
level) to produce the rendering of the stacking context itself.  It was 
very unfortunate that the term "stacking level" was used for these 
transparent plastic sheets instead of something like "painting layer", 
because it was too easily confused (even by 9.9.1 itself!) with "stack 
level" (which is a number).

This whole concept is rather hard to grasp at first for two reasons. 
Firstly, it is a recursive process:  a context C is created as a 
composite of its painting layers, but it is then treated atomically as 
just another box on the appropriate(*) painting layer in its containing 
context.

(*) as determined by the stack level of C, which is itself determined by 
the nature of C (positioned with integer z-index, positioned without 
integer z-index, float, inline-table, inline-block, root element, etc.)

[The second reason, which is irrelevant to this particular post, is that 
there are 'first-class' contexts (generated by positioned elements with 
integer z-index, for example) and 'second-class' contexts (generated by 
floats, for example).  This distinction is fundamental to determining 
the containing context of a box; box containment within the rendering 
tree does /not/ necessarily correspond to element containment within the 
document tree.  [1] discusses this in more detail.]

As is often the case, this stuff is vastly easier to understand with the 
help of a diagram.  (We wouldn't try to explain the box model without a 
diagram; and yet the stacking mechanism, which is considerably more 
complex than the box model, does not currently have one!)  I will 
attempt to produce a sketch if someone will offer to convert it into a 
nice graphic.

Returning to Ingo's specific concern: he pointed out that there cannot 
be a term like "stacking level" for an inflow block element because it 
is split into (at least) two entities, namely background + borders, and 
inline boxes.  This is correct:  there is certainly no such thing as a 
"stacking level of an element".  /Boxes/ have stack levels (and hence 
lie on stacking levels/painting layers), not elements (which are a 
conglomerate of boxes).  [An in-flow block-level element, for example, 
consists of a box holding its background and borders (its "box model 
box") plus a box for each of its anonymous block boxes and a box for 
each of its line boxes and a box for each of their anonymous inline 
boxes and a similar set of boxes for each of its descendant elements 
including one for each of /their/ line boxes, and so on.  These boxes 
have different stack levels, depending on their nature.]

Happily there is no need to worry, because Appendix E doesn't mention 
"stacking level" at all.  And nor should it: after all, stacking 
levels/painting layers are merely an abstraction of Appendix E designed 
to help us visualize the the dry numerical stack levels that it 
discusses.  There is no problem with Appendix E; the problem lies with 
its leaky abstraction in 9.9.1.

[Incidentally, all of this neatly ignores the question of what the 
undefined term "box" is rigorously supposed to mean in the context of 
9.9.1 or indeed the whole of CSS2.1 (where the term appears abundantly). 
  I didn't query this in my original paper because it looked like a bit 
of a "Pandora's box" :-)]


[1] http://dev.moonhenge.net/css21/spec/z-index/
[2] http://dev.moonhenge.net/css21/spec/z-index/css21_zindex_proposal1.html


Cheers,

Anton Prowse
http://dev.moonhenge.net


fantasai wrote:
 > Ingo Chao wrote:
 >> 2008/7/3 fantasai <fantasai@inkedblade.net>:
 >>> Ingo Chao wrote:
 >>>> Hi
 >>>>
 >>>> 2008/7/3 fantasai <fantasai.lists@inkedblade.net>:
 >>>>
 >>>>> Recorded as CSS2.1 Issue 60:
 >>>>>  http://csswg.inkedblade.net/spec/css2.1#issue-60
 >>>> Can you add the issues
 >>>> http://lists.w3.org/Archives/Public/www-style/2008Jan/0057.html
 >>>> to the record? I did not get an answer from Hixie that would change my
 >>>> concerns, and they are not listed in Anton's paper.
 >>> Hi Ingo,
 >>> I think the issue you raise there is covered by
 >>>  http://dev.moonhenge.net/css21/spec/z-index/#stacking-layer
 >>> no?
 >>
 >> Anton does not explicitly say that Appendix E cannot use "stacking
 >> level", even if the term is rephrased, because the background and
 >> inline box of an element are considered independently, on different
 >> positions in the painting order. If it cannot be used in Appendix E,
 >> then it should not be introduced in 9.9.1
 >
 > Ok. Can you and Anton work together to get all these issues
 > addressed by his proposal? This is a very complex part of the
 > spec: there aren't very many people who understand it and I'm
 > not one of them. I promise I'll get the CSSWG to look at it,
 > even if I have to spend hours with a printout and learn it all
 > myself so I can explain it at a face-to-face meeting. But it
 > would help a lot, given how much revision this section seems
 > to need, if you could incorporate your suggestions with his.
 > I can't really give you a good response right now, as I barely
 > understand what I'm reading. :(
 >
 >> If a float is followed by an inflow block, then the float sits over
 >> the background of the block. But the line box of the block can be
 >> pulled over the float by a negative margin on the float.
 >>
 >> The float sits in between the inflow block's background and line boxes.
 >>
 >> That shows that there cannot be a term like "stacking level" for the
 >> inflow block element at all. It is split into two entities.
 >>
 >> It doesn't matter much if stacking level and stack level can be easily
 >> confused or not. A stacking level simply does not exist.
 >>
 >>
 >> You once said I could ask Hixie, and he replied to my offlist question
 >>
 >>> 2008/1/15 Ian Hickson <ian@hixie.ch>:
 >>>> On Tue, 15 Jan 2008, Ingo Chao wrote:
 >>>>> ... All the colleagues I asked do have
 >>>>> difficulties in understanding 9.9.1, too. Do you know whether my
 >>>>> points
 >>>>> are valid or not? ...
 >>>> If 9.9.1 is confusing, just ignore it. It's subsumed by Appendix E
 >>>> anyway.
 >>>>
 >>>>
 >>>>> Basically, my question is: If there is no place for the term "stack
 >>>>> level" in Appendix E, and Appendix E is the more thorough
 >>>>> explanation of
 >>>>> the stacking order, why does 9.9.1 introduce this term?
 >>>> Historical reasons, I think. (We wrote 9.9.1 years before App. E.)
 >
Received on Monday, 14 July 2008 20:45:05 GMT

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