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

[css3-color] Definition of 'opacity' makes no sense for block-inside-inline situations

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Mon, 30 May 2011 23:32:25 -0400
Message-ID: <4DE46149.7010205@mit.edu>
To: www-style list <www-style@w3.org>
http://www.w3.org/TR/2010/PR-css3-color-20101028/#transparency says:

     "Conceptually, after the element (including its descendants) is
      rendered into an RGBA offscreen image, the opacity setting
      specifies how to blend the offscreen rendering into the current
      composite rendering."

The problem is that in the case of block-inside-inline, the element's 
boxes are painted completely before the block child's boxes (CSS 2.1 
Appendix E.2 step 7 will paint all inline kids of a block before 
painting its block kids).  So "after the element (including its 
descendants)" is nonsensical because you can have content sitting 
between the inline and the block kid in z-order.

Note that making the inline a generate a stacking context (which opacity 
does) doesn't help, since for inlines generating stacking contexts the 
painting specified in Appendix E.2 step 6 says to just paint the boxes 
of the inline that are in line boxes and does NOT say to paint the 
block.  This means that the block child is painted in the normal way as 
a block child of the nearest ancestor block of the inline in E.2 step 7.

I believe the text here needs changing to explicitly reference the exact 
part of the painting from CSS2.1 Appendix E that has opacity applied 
instead of trying to handwave the behavior.

In terms of current implementations, Gecko, WebKit, and Presto do not 
apply the opacity value to the child block.  Looks like IE9 does apply 
the opacity value to the child block.

There is a testcase at 
https://bugzilla.mozilla.org/attachment.cgi?id=536139 if you want to try it.

Received on Tuesday, 31 May 2011 03:32:53 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:50:01 UTC