layers and zindex in Safari

[David Hyatt]

I looked at these changes.  I really like them.  The idea of having the 
layers hold onto their own sorted lists is a great simplification.

The one thing that looks broken to me at first glance is clipping, but 
I could be wrong.  I'll need to study the code more first.  Also the 
negative z-index thing that we've been talking about.

One really minor nitpick: the term "PositionedLayer" won't be correct 
in CSS3, since elements that use "opacity" establish their own stacking 
contexts without necessarily being positioned.  I'd just go with 
something generic like "LayerElement."

dave

On Saturday, August 30, 2003, at 8:09 AM, Lars Knoll wrote:

> On Thursday 28 August 2003 20:41, David Hyatt wrote:
>> This is how WinIE behaves with negative z-index, and this was the
>> source of bugs on several sites.  (I'll try to hunt up the sites for
>> reference)
>
> I'm not sure, but as I interpret your handling it's not really 100% 
> compatible
> with the draft you quote below.
>
> Anyways, I've significantly cleaned up the render_layer code in our 
> CVS now,
> and (apart from bugs I've surely introduced) khtml in our CVS (in the 
> HEAD
> branch) should be compliant to the rules below now.
>
> You might be interested in the code. It's significantly cleaner and 
> doesn't do
> a recalculation of the z indexed list with every paint and mouse event.
>
> Cheers,
> Lars
>
>> Also, the CSS2.1 spec is going to clarify the behavior of negative
>> z-index, and the behavior of painting the background at -infinity
>> (behind the negative z-index children) is going to be the correct
>> behavior.
>>
>> Here is the current text from the next iteration of the
>> not-yet-published CSS2.1 draft.
>>
>> "Each stacking context consists of the following stacking levels (from
>> back to front):
>> 	 1.  	the background and borders of the element forming the stacking
>> context.
>> 	 2.  	the stacking contexts of descendants with negative stack 
>> levels.
>> 	 3.  	a stacking level containing in-flow non-inline-level 
>> descendants.
>> 	 4.  	a stacking level for floats and their contents.
>> 	 5.  	a stacking level for in-flow inline-level descendants.
>> 	 6.  	a stacking level for positioned descendants with 'z-index:
>> auto', and any descendant stacking contexts with 'z-index: 0'.
>> 	 7.  	the stacking contexts of descendants with positive stack 
>> levels."
>>
>> Basically this gives you total control, since you can establish a
>> stacking context yourself (by specifying an integer z-index), thus
>> ensuring negative z-index children paint above your background, or you
>> can specify a z-index of auto in which case the negative z-index
>> children will be sorted in your parent's stacking context and will
>> paint behind your background.
>>
>> dave
>>
>> On Friday, August 29, 2003, at 3:29 AM, Lars Knoll wrote:
>>> Hi,
>>>
>>> I found the following comment in safaris render_layer code:
>>>
>>>     // Find out if we have any elements with negative z-indices in 
>>> this
>>> stacking context.
>>>     // If so, then we need to split our layer in two (a background
>>> layer and a
>>> foreground
>>>     // layer).  We then put the background layer before the negative
>>> z-index
>>> objects, and
>>>     // leave the foreground layer in the position previously occupied
>>> by the
>>> unsplit original.
>>>
>>> The code which does this doesn't seem to make sense to me. Negative 
>>> and
>>> positive z-indices seem to be treated differently concerning the
>>> painting of
>>> backgrounds even though the CSS specs treats them equally (the way 
>>> you
>>> currently trat positive z-indices).
>>>
>>> Could you tell me the reason why you treat these differently?
>>>
>>> Thanks,
>>> Lars
>>>
>>> _______________________________________________
>>> Khtml-devel at mail.kde.org
>>> http://mail.kde.org/mailman/listinfo/khtml-devel
>>
>> _______________________________________________
>> Khtml-devel at mail.kde.org
>> http://mail.kde.org/mailman/listinfo/khtml-devel
> _______________________________________________
> Khtml-devel at mail.kde.org
> http://mail.kde.org/mailman/listinfo/khtml-devel