Hacker News Reader

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?

View on HN

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

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

Interesting. Seems like something that should be exposed more explicitly.

Apply Chesterton's Fence principle and assume there are (hopefully) comments in the real code around why this has been put in place

Reply on news.ycombinator.com