401682 - setting css opacity < 1 on elements changes stacking order of elements

Status: RESOLVED INVALID

(Core :: Layout, defect)

Description

[Leon Sorokin]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) Gecko/2007102904 Minefield/3.0a9pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) Gecko/2007102904 Minefield/3.0a9pre

the summary pretty much covers it.

Reproducible: Always

Steps to Reproduce:
1. open provided url
2. view source
3. work magic to fix it :)
Actual Results:  
first image...and probably second also are both layered above their containing elements and latter elements.

Expected Results:  
first image renders underneath second list element..as it does in opera 9.50 beta.

Comment 1

[Ria Klaassen (not reading all bugmail)]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) Gecko/2007103008 Minefield/3.0a9pre

I see the same as in Opera, but when I change the font to Verdana, item 2 is positioned below item 1.
http://img98.imageshack.us/img98/2007/opacityri3.png

Comment 2

[Leon Sorokin]

there seems to be more to this bug...maybe another bug.

When i change the font in the firefox options to anything other than Times New Roman, my layout changes and the list items display one below the other, not inline like in Ria's screenie above.

Same thing also happens if i change the Times New Roman font size to anything below 12pt.

odd things indeed,
Leon

Comment 3

[philippe (part-time)]

Gecko is correct (and WebKit behaves the same). When opacity is applied to an element it affects the stacking context, just as z-index would do.

From http://www.w3.org/TR/CSS21/visuren.html#z-index:
"Stacking contexts are not necessarily related to containing blocks. In future levels of CSS, other properties may introduce stacking contexts, for example 'opacity'."

"Opacity does affect z-ordering, just like position:relative does. (This would be clear in any CSS3 version of http://www.w3.org/TR/CSS21/zindex.html , but opacity isn't in CSS2.1, so it's not described there.)"
Quoted from an email to the CSS-D mailing list by David Baron: http://archivist.incutio.com/viewlist/css-discuss/69890

comment 2 is an unrelated issue, it might be worth its own bug if it doesn't exist (I haven't investigated what is going on).

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

The spec is now a lot clearer on this matter.  See http://www.w3.org/TR/css3-color/#transparency which says:

Since an element with opacity less than 1 is composited from a single offscreen
image, content outside of it cannot be layered in z-order between pieces of
content inside of it. For the same reason, implementations must create a new
stacking context for any element with opacity less than 1. If an element with
opacity less than 1 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’ and ‘opacity:
1’. If an element with opacity less than 1 is positioned, the ‘z-index’
property applies as described in [CSS21], except that ‘auto’ is treated as ‘0’
since a new stacking context is always created. See section 9.9 and Appendix E
of [CSS21] for more information on stacking contexts. The rules in this
paragraph do not apply to SVG elements, since SVG has its own rendering model
[SVG11].

(In other words, this bug is still invalid.)