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

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

From: L. David Baron <dbaron@dbaron.org>
Date: Tue, 13 May 2008 17:00:55 -0700
To: www-style@w3.org
Message-ID: <20080514000055.GA21769@pickering.dbaron.org>

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 00:01:32 GMT

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