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

Add popover light dismiss integration #460

Open
wants to merge 2 commits into
base: gh-pages
Choose a base branch
from
Open

Add popover light dismiss integration #460

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
fd18178
Add popover light dismiss integration
josepharhar Nov 22, 2022
2286d66
remove target parameter
josepharhar Jan 27, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 2 additions & 0 deletions index.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -409,6 +409,8 @@ <h2>Firing events using the <code>PointerEvent</code> interface</h2>
<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>Run <a href="html.spec.whatwg.org/#popover-light-dismiss">light dismiss open popovers</a> given the event.</p>
Copy link
Contributor

Choose a reason for hiding this comment

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

In the chromium implementation, light dismiss from the escape key seems to only be invoked if the default wasn't prevented[1]. However, calling it here before the event has been fired means that this will happen regardless of whether the default was prevented for pointer events. This indeed matches the implementation but are we intentionally inconsistent? Has there been discussion about this? I put together a demo at https://jsbin.com/bakoxan/edit?html,js,output to show a page which calls preventDefault on all events after a popover or dialog is open to test the differences.

Our implementation only calls the light dismiss steps if the event is pointerdown or pointerup. I see the steps in the html spec only care about pointerdown and pointerup, but might be worth limiting this here?

I have some concerns about the algorithm in the html spec. It seems like https://html.spec.whatwg.org/#popover-light-dismiss is replicating a form of click detection, however not taking into account many of the cases in which clicks are not generated.

  • Do you really want to light dismiss popovers on the pointerup event if the finger was moved sufficiently such that a click wouldn't be generated?
  • The check of whether the down target is the same as the up target seems a bit overly naive, in complex pages it's possible for the pointer to drift slightly and be over a different target element. Should this really result in not dismissing the popover even though it still generates a click?

I wonder whether it would be better to look for click events.

Apologies if these things have already been discussed I just couldn't find them with the searching that I did.

Copy link
Author

Choose a reason for hiding this comment

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

The reason I'm putting this here instead of in the HTML spec is that I got feedback during the review that we shouldn't be using an event listener to do the light dismiss behavior or really interacting with the event system at all, and that instead we should be going where the events are fired and instrumenting everything there. The lack of preventDefault support seems consistent with that idea.

Perhaps the escape key behavior should do the same if that is really what's preferred. I'm not sure if CloseWatcher, which should replace the current escape key implementation, imposes any changes in behavior regarding preventDefault. @domenic

It seems like https://html.spec.whatwg.org/#popover-light-dismiss is replicating a form of click detection, however not taking into account many of the cases in which clicks are not generated.

I agree, reusing the implementation of click events sounds better. @mfreed7 I believe that your initial implementation used mouseup and mousedown instead of click. Am I right? Was there any reason for that?

Copy link

Choose a reason for hiding this comment

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

Perhaps the escape key behavior should do the same if that is really what's preferred. I'm not sure if CloseWatcher, which should replace the current escape key implementation, imposes any changes in behavior regarding preventDefault. @domenic

CloseWatcher works per https://wicg.github.io/close-watcher/#close-signals ; note steps 2 and 3. (Also note that per discussion in whatwg/html#9132 (comment), @emilio would prefer we be more explicit about it being keydown for Esc, instead of my current proposal's "Fire any relevant event ... If multiple such events are fired, the user agent must pick one for the purposes of the following steps.")

Copy link
Author

Choose a reason for hiding this comment

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

I wonder whether it would be better to look for click events.

If we wanted to use the click event instead, should it be added here? https://w3c.github.io/uievents/#event-type-click

I think I have to find some place outside of the HTML spec to implement this, unless we can add some abstraction in the HTML spec for this kind of behavior. Potentially related: whatwg/html#10762


<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>

<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