Change light dismiss to use click events #11536
Conversation
This PR replaces the existing pointerdown and pointerup listening and tracking with algorithms which use a click event. The click event is going to be used by the pointerevents spec here: w3c/pointerevents#460 Using click events instead of doing click detection with pointerdown and pointerup fixes a number of issues which are detailed here: w3c/pointerevents#542 Fixes whatwg#10905
foolip
left a comment
foolip
left a comment
There was a problem hiding this comment.
Editorially looks good and makes a lot of things simpler. I just have opinions about types :)
|
@annevk @smaug---- do yall have any feedback on this? |
|
I'm likely missing something here, but since mousedown triggers select's popup to be shown, aren't there cases when just relying on click here then immediately dismisses it. |
Good catch! I'm working on a fix for this, I'll try putting it in this spec PR after I get something that works well. |
|
Here is the aforementioned fix for the immediate light dismiss: #12008 |
|
If I understand correctly, this PR will change user-facing behavior from: (the arrows indicate a to 
If this isn’t intentional, I can suggest fixes. demo: https://codepen.io/sb3nder/pen/qEZpXqL Regarding #12008, I wonder if it would be better to apply the same behavior to non‑select popovers. I can suggest a small change that wouldn’t require a flag. |
|
Thanks for the images, but I'm having a hard time understanding the behavior difference. The change is released in chrome canary with experimental web platform features enabled: chrome://flags/#enable-experimental-web-platform-features Do you think you could test it out and share a video? Or give a list of steps I can read to repro the change in behavior? |
|
Thank you, I tested with the Experimental Web Platform features enabled, and everything works fine for me: But I’m having a hard time understanding from the spec how, with just the click target, it is able to differentiate the various cases. For example, if I click-drag from a popover to Thank you. |
|
Ah good point I messed this up in the process of rewriting the chromium patch several times, I'll update this and the pointerevents spec PR soon |
|
Ok it should have substantially more detail now, please take a look. I also updated the pointerevents spec PR accordingly |
| </ol> | ||
| </li> | ||
| <li><p>If <var>pointerDownPopover</var> is the same as <var>pointerUpPopover</var>, then run | ||
| <span data-x="hide-all-popovers-until">hide all popovers until</span> given <var>ancestor</var>, |
There was a problem hiding this comment.
| <span data-x="hide-all-popovers-until">hide all popovers until</span> given <var>ancestor</var>, | |
| <span data-x="hide-all-popovers-until">hide all popovers until</span> given <var>pointerDownPopover</var>, |
|
Looks good to me!
|
5 participants
This PR replaces the existing pointerdown and pointerup listening and tracking with algorithms which use a click event. The click event is going to be used by the pointerevents spec here:
w3c/pointerevents#460
Using click events instead of doing click detection with pointerdown and pointerup fixes a number of issues which are detailed here: w3c/pointerevents#542
Fixes #10905
(See WHATWG Working Mode: Changes for more details.)
/infrastructure.html ( diff )
/interactive-elements.html ( diff )
/popover.html ( diff )