layers and zindex in Safari

[David Hyatt]

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.
>

Yes, it's probably not 100% compatible.  That text was written after I 
implemented the layer code.  It should be fairly close though.

>>  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 in the above list, 1 corresponds to the paintaction where you 
only paint your background, 2 is handled by the layer code sorting, 3 
is the background phase where you paint children's backgrounds 
(non-inline-level descendants have no foregrounds to paint, and inlines 
don't paint during this phase), 4 is the float phase, 5 is the 
foreground phase (during which inline elements fully paint), and 6 and 
7 are handled by the layer code sorting.

I really should rename BackgroundChildren to Block and Foreground to 
Inline, since that's basically how they work in the code right now.

Anyway, I think the current code is pretty close.  The big ambiguity is 
how to handle tables.

> 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.
>

Cool, I'll take a look.  Avoiding the recalculation was on my list of 
things to do.

dave

> 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