Explain how a removed DOM node should be handled for boundary events. #491
Conversation
This explains how the previous target is tracked when the previous target is removed from the DOM for w3c#477.
| and reset the |over child| flag to <code>false</code>. | ||
| If the |previous target| at any point will no longer be [=connected=] [[DOM]], | ||
| update the |previous target| to the nearest still [=connected=] [[DOM]] parent | ||
| following the event path corresponding to dispatching events to the previous target, |
There was a problem hiding this comment.
Note that this following the event path part is a bit hand wavy. Maybe we need to expose a method which encapsulates step 5.9 of dispatching events. One of the complications to doing that is the get the parent algorithm can depend on the particular event being dispatched. I think it is the case that for all pointer events (and mouse events) the path is expected to be the same, but technically nothing stops a particular event from having a different path.
There was a problem hiding this comment.
I guess it is better to land this hand wavy patch and maybe file a followup to think about how to spec it in a more algorithmic way.
|
@smaug---- @mustaqahmed thoughts on this PR? |
index.html
Outdated
| @@ -423,7 +423,17 @@ <h3>Firing events using the <code>PointerEvent</code> interface</h3> | |||
| <p>If the event is {{GlobalEventHandlers/pointerdown}}, the associated device is a direct manipulation device, and the target is an {{Element}}, | |||
| then <a>set pointer capture</a> for this <code>pointerId</code> to the target element as described in <a>implicit pointer capture</a>. | |||
|
|
|||
| <p>Fire the event to the determined target. The user agent SHOULD treat the target as if the pointing device has moved over it for the purpose of <a data-cite="uievents/#events-mouseevent-event-order">ensuring event ordering</a> [[UIEVENTS]].</p> | |||
| <p>Fire the event to the determined target. | |||
| The user agent SHOULD treat the target as if the pointing device has moved over it from the |previous target| (or if the |over child| flag is set, over an anonymous child of |previous target|) | |||
There was a problem hiding this comment.
What is an anonymous child?
There was a problem hiding this comment.
The idea is to treat the pointer as if it is not yet over the parent. E.g. if you have
<div id="a">
<div id="b">Pointer over</div>
</div>And you remove #b while the pointer is over it, the next boundary update should dispatch pointerover #a. If we implicitly set the pointer to be over #a then we will never dispatch this - so I'm proposing that we have some state that tracks that it is like being over a child of #a - but one which doesn't actually exist in the dom to receive events - for the sake of being able to dispatch the correct boundary events on the next update.
There was a problem hiding this comment.
Happy to bikeshed on better ways to describe this / or define and explain a term for this.
There was a problem hiding this comment.
I've replaced the "anonymous child" mention with a flag that directly states the over event is needed.
patrickhlauke
added
the
needs-wpt
mustaqahmed
removed
the
needs-wpt
|
Removing the need-wpt label because #477 has it already. |
This explains how the previous target is tracked when the previous target is removed from the DOM for #477.
Preview | Diff