Re: [css3-color] Interaction of 'opacity' and z-ordering rules

I agree with all of these proposed changes.   WebKit differs from  
Gecko on issue 3 because of a bug:

https://bugs.webkit.org/show_bug.cgi?id=16130

dave
(hyatt@apple.com)

On May 13, 2008, at 7:00 PM, L. David Baron wrote:

>
> Anne raised http://csswg.inkedblade.net/spec/css3-color#issue-26
> regarding the opacity property needing to specify that a new
> stacking context is created.  I did a bit of testing (in Gecko,
> WebKit, and Opera) and found that there are three separate issues
> (two that the spec must address, and a third that it could address
> and where implementations currently differ).
>
> Issue 1: Elements with opacity always create a new stacking context.
>
> This is the non-controversial issue (all three implementations
> match).  This means that any z-ordering that occurs inside the
> element stays within it, and does not leak out.  This is required,
> conceptually, since everything inside the element has to be
> composited against its background, atomically.
>
>
> Issue 2: At what layer should elements with opacity be painted?
>
> In http://www.w3.org/TR/2007/CR-CSS21-20070719/zindex.html CSS 2.1
> defines the painting order for all elements within their parent
> stacking context.  It says that positioned elements with 'z-index:
> auto' or 'z-index: 0' are painted at a different layer (8) from
> non-positioned elements (which are split between layers (4)-(7)).
> Since elements with opacity must be composited atomically, their
> text/inlines cannot be painted at a different layer from their
> background, so I claim that it does not make sense to use layers
> (4)-(7) for elements with opacity.  (It would be possible, though,
> if one said that the *entire* element went in one of those layers,
> but it would create yet another type of behavior that doesn't
> currently exist.)  Therefore I think that elements with opacity
> should appear along with positioned elements at layer (8).
>
> This matches the behavior of Gecko and Webkit, but not Opera.  (I
> haven't tested Opera in enough detail to be sure which alternative
> behavior it follows.)
>
>
> Issue 3: Should the z-index property apply to elements with opacity?
>
> Based on the current wording in the spec, it should not, and the
> spec *is* currently internally consistent here (which it is not on
> the previous two issues).
> http://www.w3.org/TR/2007/CR-CSS21-20070719/visuren.html#z-index
> says that z-index applies only to positioned elements.  However,
> given that elements with opacity have (given the resolution to issue
> 2 above) all the other z-ordering behavior of positioned elements,
> maybe it should.
>
> Right now, Safari applies z-index, but Gecko and Opera do not unless
> the element is positioned.
>
>
> I've written a draft test for this (that tests the majority
> behaviors for both issue 2 and 3) at:
> http://dev.w3.org/CSS/css3-color-test-suite/src/t32-opacity-zorder-c.xhtml
>
>
> I propose addressing  these issues by adding the following paragraph
> to the end of section 3.2 of
> http://dev.w3.org/csswg/css3-color/#transparency :
>  # Since an element with opacity is composited from a single
>  # offscreen image, content outside of it cannot be layered in
>  # z-order between pieces of content inside of it.  Therefore,
>  # implementations must create a new stacking context for any
>  # element with opacity.  If an element with opacity is not
>  # positioned, implementations must paint the layer it creates,
>  # within its parent stacking context, at the same stacking order
>  # that would be used if it were a positioned element with
>  # 'z-index: 0'.  If it is positioned, the 'z-index' property
>  # applies as described in [[CSS21]].  See <a
>  # href="http://www.w3.org/TR/CSS21/visuren.html#layers">section
>  # 9.9</a> and <a
>  # href="http://www.w3.org/TR/CSS21/zindex.html">Appendix E</a> of
>  # [[CSS21]] for more information on stacking contexts.  The rules
>  # in this paragraph do not apply to SVG elements, since SVG has
>  # its own <a
>  # href="http://www.w3.org/TR/SVG11/render.html">rendering
>  # model</a> [[SVG11]].
> If we choose to go the other way on Issue 3, this text would be
> relatively easy to modify.
>
> -David
>
> -- 
> L. David Baron                                 http://dbaron.org/
> Mozilla Corporation                       http://www.mozilla.com/
>

Received on Wednesday, 14 May 2008 16:49:32 UTC