3 ms·
But they're already checking for event.name == 'click' in the revised code. So why would you want to filter out some legitimate click events?
by nightpool 2y ago
But they're already checking for event.name == 'click' in the revised code. So why would you want to filter out some legitimate click events?
- kulor 2y agoApply Chesterton's Fence principle and assume there are (hopefully) comments in the real code around why this has been put in place
- marcellus23 2y agoMaybe browsers will report `click` events that aren't actually created by a pointer device (maybe a screen reader or something?). But that still raises the question of why you would care. It seems to me like if the platform wants to report it as a `click`, your app should treat it as one and not try to get "clever" about it.
- pornel 2y agoFor compatibility with the Web content, the `click` event has become a device-independent activation event. Sites can't be expected to listen for events from every kind of device, so instead all devices send `click`s. They care, because focus for keyboard-controlled screen readers sending "click" should behave differently: an element inside the menu should receive focus, even though it's not the element that has been clicked. Otherwise if focus stayed on top-level menu bar, screen reader users would be lost, and had to navigate to menu's content themselves.
- marcellus23 2y agoInteresting. Seems like something that should be exposed more explicitly.