- From: Anton Prowse <prowse@moonhenge.net>
- Date: Mon, 14 Jul 2008 22:44:52 +0200
- 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 UTC