joshtumath

Well that's just one example. Most websites have problems. Especially on mobile viewports.

Actually I don't think the explainer gets into the full story. The reality is it's not CSS's problem. It's the browsers that have historically made text scaling weird on each platform that they support.

And now just like with the viewport meta tag, we need a meta tag to say, 'Stop doing that please. Make the default font size in my CSS work the way it always should have'.

The other reason why the flag can't be in CSS is because it needs to make em and rem units in media queries get affected by the user's text scale. See the explainer for more info on that.

Actually that is what we're going to do. I'm hoping to merging in code, soon, that will change it to use pointerId === -1 and then fall back to screenX === 0.

At the time this code was originally written four years ago or whenever it was, not all browsers used PointerEvent for click.

I omitted that code to keep the article simpler. We want to turn off the animation on keyboard, and move the focus to different things depending on if it's a keyboard or pointer user.

Well said! It certainly applies to web development as well. Sadly, sometimes more complex solutions are needed - especially when based on user research.

I am the author.

> The first mistake the developer made, was that he wanted to create a different user experience between keyboard and mouse. Stick to what you get by default and design your components so they work for both usecases.

We have. The behaviour is mostly the same whether you're using the keyboard or a pointer (mouse/touch/pen). The only difference is that, for keyboard users, we want to turn off the animation and move the focus to the first link in the menu instead of focussing on the menu's parent <ul>.

The problem was that, as various devs have iterated on the menu over the years, it's broken the fallback behaviour. For my colleague on the funny multi-monitor set up, it should have fallen back to the keyboard no-animation behaviour with no real major difference to the UX, but instead it fell back to the no-JS experience.

So yes, generally don't try to be smart with accessibility, avoid ARIA attributes except where necessary, etc, but click events are the universal input event and work on any kind of input device and have perfect browser support. It's far better for accessibility using them instead of a mix of keydown and mousedown or pointerdown, and potentially missing other kinds of input events.

As I stated in another comment, if it was a scenario where there needs to be a major difference in behaviour between keyboard and pointers, then I would rather use separate keydown and pointerdown events.

Hello I am the author and, yes, I totally agree some generic 'trigger' event would be far better.

To use the keydown event means we have to assume that the 'Enter' and 'Space' are the only keys we need to check for. Using 'click' is far safer from an accessibility point of view because it will always respect what your device considers to be some kind of input trigger.

As stated in the UI Events spec:

> For maximum accessibility, content authors are encouraged to use the click event type when defining activation behavior for custom controls, rather than other pointing-device event types such as mousedown or mouseup, which are more device-specific. Though the click event type has its origins in pointer devices (e.g., a mouse), subsequent implementation enhancements have extended it beyond that association, and it can be considered a device-independent event type for element activation.

And to be clear, I would not want to do it this way if it was for some really critical difference in behaviour between pointer or keyboard interactions. I'm OK with this strange mechanism here because the fallback behaviour is not that different. If you're on Safari, for example, which can't check for `screenX === 0`, then all that happens is that there will be an animation when you open the menu.

However, sadly, because of the ways various developers have added to this code over the years, it's broken that fallback behaviour and stopped it working entirely. So I've just finished a refactor to sort that out and it will hopefully be going live soon.

Hello I am the author and that was indeed a mistake. Whoops!