layers and zindex in Safari

[Lars Knoll]

Hi David,

thanks a lot for your patch. You're right, my code didn't do clipping 
correctly. I'll have a look at your code and will probably integrate it into 
khtml in the next few days. 

Cheers,
Lars

On Monday 01 September 2003 10:49, David Hyatt wrote:
> Lars:
>
> Inspired by your patch, I have produced a new version of the layer code
> for Safari that avoids the recalculation of the layer list except when
> z-indices of layers change or layers are added/removed.  In this patch,
> a layer now holds onto a sorted list of positive layers and a sorted
> list of negative layers.  Think of this patch as a rough draft.  It
> needs more testing and has not yet landed in the Safari tree.
>
> With the two separate z-order lists, the paint method and nodeAtPoint
> method can be cleanly recursive.  For example, paint just does the
> following:
>
> 1. Compute the right clip rects.
> 2. Paint the element's background/border/scrollbars with the background
> clip.
> 3. Descend into the negative list, calling paint on each layer.
> 4. Paint the child content of the element with the foreground/child
> clip.
> 5. Descend into the positive list, calling paint on each layer.
>
> The one feature that is the most difficult to understand in the layer
> code is clipping.  Clipping is actually incredibly complicated, and the
> current layer code in Safari is actually very close (modulo some bugs
> with fixed positioning) to matching the CSS2.1 specification.  This new
> patch actually fixes the fixed positioning clipping bugs and is
> designed to match the spec completely.
>
> Here are some notes to help understand how clipping works.
>
> There are two completely different clip mechanisms in CSS.  The first
> is the 'clip' property.  It can be specified only on positioned
> elements but then applies to all descendants in the document tree.  The
> 'clip' property when applied to an element actually clips the *element
> itself* as well as all descendants.
>
> The second mechanism is overflow.  In CSS3, you can actually specify an
> overflow-clip property that indicates a rectangle to clip, but by
> default this overflow clip rect is the padding-box (minus the scrolling
> mechanism if one is present).  Overflow does not apply to the element
> itself, and the only descendants it applies to are those that are *in
> the containing block hierarchy* of the object.
>
> Clipping is a pain, since painting does not do a clean descent in
> document order through the layer tree because of auto z-index. You
> might have the following layer hierarchy:
>
> (Layer A with z-index 1) -> (Layer B with auto z-index that clips) ->
> (Layer C with negative z-index)
>
> In the above example, B establishes a clip that affects C, and yet when
> you do a paint that recurs through sorted layer lists, C is going to
> paint completely before B.
>
> The clip rect to use when painting also varies based on where you are
> in the containing block hierarchy.  In the above example if B is
> position:absolute and specifies an overflow clip, but C is
> position:fixed, then B should not clip C, but if C is
> position:absolute, B *should* clip C.
>
> Another point of clarification regarding the layer code itself: even
> though layers have x/y member variables, those values are *not
> necessarily relative to the parent layer*.  A layer hierarchy does not
> match containing block order, so you can have layers like so:
>
> (Layer A Non-Positioned) -> (Layer B Abs Pos) -> (Layer C Fixed Pos)
>
> The x/y coords of C are not relative to B, nor are the coords of B
> relative to A in the above example.
>
> This patch (like the old code did) handles most of these bizarre
> combinations correctly.
>
> Another feature of this new patch is that it fixes the remaining
> problems with nodeAtPoint and hover.  The old Safari code could
> mistakenly set hover on two overlapping elements, when only one should
> have gotten the hover state set.  This new code is much more efficient
> in its handling of :hover and fixes this problem.
>
> Here is a diff against the current Safari tree along with the
> render_layer.h/cpp files, since they'll probably be easier to read by
> themselves.
>
> Cheers,
> Dave
> (hyatt at apple.com)