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.
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
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
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).
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.)