- From: <bugzilla@jessica.w3.org>
- Date: Mon, 01 Oct 2012 03:43:43 +0000
- To: public-webapps-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18912 --- Comment #6 from Dominic Cooney <dominicc@chromium.org> 2012-10-01 03:43:42 UTC --- (In reply to comment #5) > In that case, the most logical spot to add an event listener would be in the > ShadowRoot that contains the element, which would then have the correct scope > for an elementFromPoint call. Events get routed through <content> and <shadow> elements, so returning the <content> or <shadow> element is more precise than the shadow root. However since <content> and <shadow> are not themselves rendered, it gives you the weird situation where you ask shadow.elementAtPoint(10, 50) and the offset/client properties of the result say the element is at (0,0)-(0,0). Would that be a problem? It seems like since you are already writing code that is dealing with ShadowRoot to call shadow.elementFromPoint instead of document.elementFromPoint, you could handle <content> and <shadow> specifically if you needed to. > Now, there is a larger problem here involving touch events. In the > implementation of touch events, touchmove does not change target. > This means that while the finger is moving on the screen, the same element that > received the touchstart event will receive all the touchmoves (and touchend). > In this environment, if a finger is placed outside of a ShadowRoot and moved > into it, the ShadowRoot will never receive the touchmove event, and cannot call > its version of elementFromPoint. > > This is a major problem for any polyfilled event systems (like PointerEvents: > https://github.com/toolkitchen/PointerEvents). The problem with touch is too mind boggling for me. It feels like a separate issue. If I understood what you wrote, it seems this problem would happen if the touch is moved over an ordinary div, irregardless of whether it has Shadow DOM. -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Monday, 1 October 2012 03:43:44 UTC