Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Explain how a removed DOM node should be handled for boundary events. #491

Merged
merged 2 commits into from Nov 22, 2023
Merged

Explain how a removed DOM node should be handled for boundary events. #491

Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
fd853ba
Explain how a removed DOM node should be handled for boundary events.
flackr Oct 31, 2023
6a69eda
Use a more specific needs over event flag.
flackr Nov 20, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
12 changes: 11 additions & 1 deletion index.html
View file
Open in desktop
Expand Up @@ -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|)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is an anonymous child?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Happy to bikeshed on better ways to describe this / or define and explain a term for this.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've replaced the "anonymous child" mention with a flag that directly states the over event is needed.

for the purpose of <a data-cite="uievents/#events-mouseevent-event-order">ensuring event ordering</a> [[UIEVENTS]].</p>

<p>Save the determined target as the |previous target| for the given pointer,
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,
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

and set the |over child| flag to <code>true</code>.
</p>

<div class="note">Using the <a>pointer capture target override</a> as the target instead of the normal hit-test result may fire some boundary events, as defined by [[UIEVENTS]]. This is the same as the pointer leaving its previous target and entering this new capturing target. When the capture is released, the same scenario may happen, as the pointer is leaving the capturing target and entering the hit-test target.</div>

Expand Down