Re: Additional value for the visibility property

David Hyatt wrote:
> On Jul 9, 2008, at 1:26 PM, 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.
>
> FF and WebKit have the correct rendering.  Opacity is supposed to 
> establish a stacking context (it's as though a z-index of 0 is 
> specified) precisely to avoid the problem of requiring multiple 
> buffers.  You should never have to use separate buffers.  The spec 
> vaguely implies this when it mentions that an element including its 
> children should blend as a unit.  To use separate buffers contradicts 
> what the spec is saying.
Formally speaking: current specification is buggy by itself so no one 
can prove "correct rendering".
Definition of z-index and stacking context conflicts with the opacity 
and "draw all children".

So far there are two ways of fixing this:
1) Mozilla way: 
http://lists.w3.org/Archives/Public/www-style/2008May/0147.html
2) and Opera way (explained above)

 From human perspective Opera way is most natural I would say.
It would be quite surprising if applying of opacity will change the 
whole z-index hierarchy.
>
> This issue will be clarified in the spec.
>
But how? That is the question and still subject of discussion as far as 
I understand.
> See Issue 26:
>
> http://csswg.inkedblade.net/spec/css3-color
>
> http://lists.w3.org/Archives/Public/www-style/2008May/0147.html
>
> dave
> (hyatt@apple.com)
>

-- 
Andrew Fedoniouk.

http://terrainformatica.com

Received on Wednesday, 9 July 2008 19:26:12 UTC