- From: Simon Fraser <smfr@mac.com>
- Date: Thu, 10 Jul 2008 05:46:36 +0000
- To: Andrew Fedoniouk <news@terrainformatica.com>
- Cc: robert@ocallahan.org, "Ph. Wittenbergh" <jk7r-obt@asahi-net.or.jp>, W3C Style List <www-style@w3.org>
On Jul 9, 2008, at 11:26 AM, Andrew Fedoniouk wrote: > Robert O'Callahan wrote: >> On Wed, Jul 9, 2008 at 3:27 PM, Andrew Fedoniouk <news@terrainformatica.com >> <mailto:news@terrainformatica.com>> wrote: >> >> That is what I would like to clarify - how exactly it should be >> rendered. >> >> >> I think it's clear that according to the spec it should be rendered >> the way Gecko and Webkit render it. >> >> If you're suggesting that the spec should be changed --- this has >> been specified and interoperably implemented in Gecko and Webkit >> for years, so I think you'd need a pretty strong argument. >> Personally it feels unnatural to me to render an element and its >> descendants as a single composition group but carve out an >> exception for descendants that happen to be out-of-flow. (Although >> I'm not actually sure what you're proposing, since there might be >> descendants which are out-of-flow but still have the element as >> their containing block ancestor.) > Opacity is an attribute of some layer. Element and its in-flow > descendants is a layer. absolute positioned elements > establish their own layers. > > It appears that Opera: > 1) draws element and only in-flow children on the offscreen buffer > (layer) > 2) each absolute positioned element - descendant of transparent > parent - inherits value of opacity and draws > itself on separate offscreen buffer (layer). > 3) these buffers are blended separately with respect of z-order. > > That appear as the only correct way of doing this. > > FF and WebKit share the same error. Take a look on these samples: > > http://terrainformatica.com/w3/opacity.htm > http://terrainformatica.com/w3/no-opacity.htm > > These two files are the same except of transparency. > Note that FF and WebKit simply ignore value of z-index when opacity > is applied. Actually the behavior is correct in FF and WebKit, which create stacking contexts for elements with non-1 opacity. CSS 2.1 says (<http://www.w3.org/TR/CSS21/visuren.html#layers >): "Stacking contexts are not necessarily related to containing blocks. In future levels of CSS, other properties may introduce stacking contexts, for example 'opacity' " In <http://terrainformatica.com/w3/opacity.htm>, div.container has opacity, and therefore sets up a stacking context. This means that 'kid' is rendered into that stacking context. 'stranger' does not share that stacking context, and is thus rendered on top. In <http://terrainformatica.com/w3/no-opacity.htm>, all elements share the same stacking context, so the z-index on 'kid' brings it in front of the other two elements. Simon
Received on Wednesday, 6 August 2008 14:22:58 UTC