[Webkit-unassigned] [Bug 90419] When overlap testing, compute regions relative to some container, not absolute

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=90419





--- Comment #8 from Shawn Singh <shawnsingh at chromium.org>  2013-01-22 15:23:46 PST ---
(In reply to comment #7)
> I ran onto similar issue when rotated element overlaps another element, which is on top of it.
> 
> In Chrome the top element seems to be correctly placed (no overlap is visible), but once you try to hover it - after a certain point the hover is not working anymore.
> 
> In Safari and in the latest nighty build of standalone Webkit (r140252 at the time of writing) - you actually can see that the bottom square overlaps the top at some point.
> 
> Demo - http://codepen.io/angryObject/full/rcdHm.

Unless I misunderstood your comments - what you're seeing on that link is a different meaning of "overlap" related to hit-testing / layer sorting / preserve-3d.  Chrome and Safari may not have matching semantics (yet) about preserve-3d (or lack thereof in your example), due to different layer sorting implementation quirks.

The overlap Simon is referring to is an implementation detail when choosing what parts of the DOM can be grouped together into an accelerated composited layer; sometimes layers need to be forced to become compositing because they overlap other things that are compositing, so that we can keep the desired paint-order as per CSS 2.1 spec.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.