- From: Anton Prowse <prowse@moonhenge.net>
- Date: Wed, 19 May 2010 22:54:02 +0200
- To: "www-style@w3.org" <www-style@w3.org>
- CC: Justin Poirier <poirier.justin@gmail.com>
Hi Justin, I will address some of your points in my reply to Sylvain, and Ingo has since explained why the change you've noticed was applied. Here I will just provide a quick thought on what you were saying. > 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..." > 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. Indeed, non-positioned floats, inline blocks and inline tables, together with positioned elements with z-index:auto, have stacking context-like behaviour. You claimed that the spec change is "significant because it adds a new type of element behaviour": > 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? Certainly, z-index:auto positioned elements are unique, for the reason you describe. As for whether it was originally intended, I don't know. (Note that it's internally consistent, and implemented cross-browser, so it's certainly what's intended right now.) Either way, it forms part of the richness (and equally the complexity) of the stacking model, and my gut feeling is that we'd be poorer without it. It would certainly be /different/ without it, since now z-index:auto positioned elements escape a parent stacking context-like element such as a float, whereas before the spec change they were "stuck" in their parent, which would yield a different layout in the case where two overlapping floats both had positioned, z-index:auto children, for example. > [a] http://dev.moonhenge.net/css21/spec/z-index/ Cheers, Anton Prowse http://dev.moonhenge.net
Received on Wednesday, 19 May 2010 20:55:15 UTC