Last Comment Bug 401682 - setting css opacity < 1 on elements changes stacking order of elements
: setting css opacity < 1 on elements changes stacking order of elements
Status: RESOLVED INVALID
:
Product: Core
Classification: Components
Component: Layout (show other bugs)
: Trunk
: x86 Windows XP
: -- normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
http://www.husng.com/old/test/opacbug...
: 344361 428642 467026 490135 512297 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-10-30 05:32 PDT by Leon Sorokin
Modified: 2012-03-05 23:33 PST (History)
8 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Leon Sorokin 2007-10-30 05:32:12 PDT
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) 2007-10-30 16:46:33 PDT
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 2007-10-30 17:15:11 PDT
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) 2007-10-30 18:49:58 PDT
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+8 (review requests must explain patch) 2009-08-30 12:27:14 PDT
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.)
Comment 5 David Baron :dbaron: ⌚️UTC+8 (review requests must explain patch) 2009-08-30 12:27:28 PDT
*** Bug 428642 has been marked as a duplicate of this bug. ***
Comment 6 David Baron :dbaron: ⌚️UTC+8 (review requests must explain patch) 2009-08-30 12:27:42 PDT
*** Bug 467026 has been marked as a duplicate of this bug. ***
Comment 7 David Baron :dbaron: ⌚️UTC+8 (review requests must explain patch) 2009-08-30 12:27:49 PDT
*** Bug 512297 has been marked as a duplicate of this bug. ***
Comment 8 David Baron :dbaron: ⌚️UTC+8 (review requests must explain patch) 2009-08-30 12:30:22 PDT
*** Bug 490135 has been marked as a duplicate of this bug. ***
Comment 9 Anthony Ricaud (:rik) 2012-03-05 15:32:55 PST
*** Bug 344361 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.