On Nov 26, 2007, at 1:34 AM, Alan Gresley wrote: > Ingo Chao wrote: > >> Hi, >> >> Safari Webkit, Firefox 3b and Opera 9.5b render this test different: >> >> http://www.satzansatz.de/cssd/tmp/opacity/ >> ... >> >> The red box and the blue box have opacity set. In addition, the first >> one gets a z-index. >> > Both Safari (beta) and Opera on windows shows the same in which > opacity creates a new stacking content. > The blue box sits above the red box and the yellow box is above the > blue box it's parent, I would say this is correct for both Opera > and Safari to do this and goes along with what David Hyatt has.
The blue box sits on top of the red box because it comes last in source and it is in the same (visual) plane as the red box (or if you prefer, the same stacking level). Now, 1. Gecko does establish a stacking context for elements with 'opacity'. 2. Opera does _not_ establish any stacking context for opacity. <http://dev.l-c-n.com/_temp/rp-stacking-opacity.html> Opera puts the red box in front of the green box; Gecko and Webkit put the green box in front. see also this email from D. Baron on the subject: <http://archivist.incutio.com/viewlist/css-discuss/69890> A difference between Gecko and WebKit is that WebKit give a box with opacity set a z-index of '0', whereas Gecko gives it a z-index of 'auto'. (I think). In Ingo's test case, the red box has z-index:2, but no positioning scheme is specified. That z-index should be ignored in my book. see CSS 2.1: http://www.w3.org/TR/CSS21/visuren.html#z-index 'Applies to: positioned elements ' Webkit seems to do the following: opacity gives z-index:0 and a stacking context. Then the z-index:2 given in the ruleblock for the red box is applied, and the red box is pulled in front of the blue box. Gecko ignores the z-index:2 (no rel.pos or abs.pos declared) and thus paints the blue box in front of the red box. > Giving position:relative to #stackA brings Firefox into line with > Safari (creating a stacking content for FF). yes, in that case WebKit and Gecko should (and do) display the same thing. > This also causes Opera to now shows the yellow box opaque over the > parent's red box. Since now the yellow box is part of a stacking > content?? I'm trying to wrap my head around what Opera is doing here..., a bit inconsistent. I've noticed that elsewhere as well (some recent discussions on the WSG list). No matter what stacking environment, the yellow box should clip out the red where yellow and red overlap, because yellow is fully opaque. But what is under the whole box (red+yellow) should be partly visible - the background image in Ingo's page. It sounds like in Opera's case, the yellow box is inheriting the opacity on the red box in some case. That is wrong. > CSS3 stacking content is here, though no mentioned of opacity. > > <http://www.w3.org/TR/css3-box/#stacking> That is basically the same as in CSS 2.1: http://www.w3.org/TR/CSS21/zindex.html#painting-order > I think that the stacking context established for 'opacity' is sort of implied in the description, the offscreen buffering part in <http://www.w3.org/TR/css3-color/#transparency> In very layman's terms: at full opacity, when a box is painted on the canvas (browser window), it clips or cuts out everything that is under it. But when the box has some 'opacity' it needs to be painted on a higher layer, in order to show what is under that box. (Developers working on rendering engines will probably shoot me for this way of explaining things...). Philippe --- Philippe Wittenbergh <http://emps.l-c-n.com> ______________________________________________________________________ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
