- From: Andrew Fedoniouk <news@terrainformatica.com>
- Date: Wed, 09 Jul 2008 20:12:55 -0700
- To: David Hyatt <hyatt@apple.com>
- CC: robert@ocallahan.org, "Ph. Wittenbergh" <jk7r-obt@asahi-net.or.jp>, W3C Style List <www-style@w3.org>
David Hyatt wrote: > On Jul 9, 2008, at 4:43 PM, Andrew Fedoniouk wrote: > >> >> David Hyatt wrote: >>> On Jul 9, 2008, at 3:53 PM, Andrew Fedoniouk wrote: >>> >>>> >>>> In fact it should be rendered as this: >>>> http://terrainformatica.com/w3/opacity-probe-rendering.png >>>> as opacity is not inherited by default (so div.kid is not transparent). >>> >>> We cannot change this. I do not understand why you are just bringing >>> this up now. The vendor prefixes were dropped from opacity ages >>> ago. It's done. >> What specification was used for implementing this? That is a point. >> I doubt that any existing designs rely on the fact that opacity >> establishes new stacking context. So you can change this. >> > > opacity is used heavily in OS X, both in Dashboard widgets and in apps > that use WebKit. It has been deployed for years. Even if we could > change it, I don't think we should, since I think having opacity follow > the document tree is much more natural than having it follow the > containing block hierarchy. So you say that in OS X if you will create non-child window (that is absolutely positioned element) then that window will be somehow dependent on transparency of its owner (DOM parent element)? Say its coordinates will be relative to its semi-transparent owner and if that owner will gradually change transparency then that window will suddenly jump to the origin of the desktop. This way? Poor people... I am not against the opacity that follows the document tree. For children in normal flow - no objection, you honor. But absolute positioned elements are different creatures. Their real visual containers are so called container blocks - not DOM parent nodes. -- Andrew Fedoniouk. http://terrainformatica.com
Received on Thursday, 10 July 2008 03:13:28 UTC