* works with middle click for new tab
* integrates with accessibility devices
* works with right click + open in new window or similar options
* etc. etc. etc.
If it's notionally navigation, don't use javascript soup: use a link.
To anyone reading who has tried to get fancy with a substitute for the <a> tag, I wish you mild discomfort and inconvenience.
That person should sit alone in a room with no distractions and think about what they did.
And those devs set the wrong patterns and standards for others following hot behind them. The only time I can remember needing to dress a div up like a button was when an accordion trigger was just a giant button and anything passed in would be rendered inside, but I needed an action to the right of the trigger title. But those happen super rarely. You can't just pass in a button as it was invalid html to have nested buttons obviously. Yes, I know I could probably use css to absolutely position it or something but that takes it out of the flow and starts hacking about it in another way.
Click a link with left-mouse, and it'll intercept the page with their safety checker (that doesn't work half of the time) before forwarding you.
But middle click? No safety for you.
It might not be what the developer of the site/app intended; but it's exactly the semantics the user is expressing their desire to trigger. So why not do what the user wants? Browsers are user agents, not developer agents, after all.
(Before you say "that sounds like a layering violation" — well, yes it is, but that particular layering violation already exists to support most browsers' JS engines' "suppress popup-window / new-tab navigation if the stack of the navigating call doesn't contain a click event" logic. The code ugliness was already bought and paid for; we may as well reap as much benefit from it as we can!)
That’s not necessarily true. You could imagine writing perhaps a video game or something where this control is intended to have a different meaning. For this reason, I don’t think this is a liberty that browser developers can take.
It's not "add a browser-default click event listener that shims in special behavior" (which wouldn't be able to catch the JS navigation in the first place, since that would be occurring in its own, separate click event listener.)
It's instead "when I-the-browser have been called by page JS to do something navigation-like through the native `location` or `history` APIs, first check if the current call stack has a event-listener call triggered by a browser-delivered click event in its ancestry. If it does, check further whether the click was a "special" [middle-mouse-button / shift / ctrl-or-cmd / alt] click. If it was, then cause some other side-effect depending on the "special" modifier [i.e. open the target URL in a new tab, or new window, or download it] while silently failing to actually navigate this tab. Otherwise, proceed with the original semantics of the native `location` / `history` API call that was made."
If your game isn't specifically trying to have middle-clicking / ctrl/cmd-clicking navigate the tab, then this check+logic would never fire.
---
That being said, in theory, if you bound a listener to `auxclick` and told it to `e.preventDefault()`, that should maybe tell the browser you're doing something special and different where the middle-mouse button isn't just "the left mouse button with extra flags set", and therefore that navigation triggered via the middle mouse button shouldn't be seen as "navigation triggered via the left mouse button with extra flags set."
I say in theory because web developers would probably use that to prevent people from opening their site/app in multiple tabs at once. And the whole point here is that people should be able to do this whether web developers like it or not.
--
Also, a tangent:
Web developers may have what are, to them, good reasons for preventing the user from opening their page/app in multiple tabs.
For instance, each instance of a page/app on their site might open its own persistent websocket connection to their backend, and so having O(N) tabs open to their site means O(N) websocket connections. And if many users do that, their backend falls over.
Or each instance of the page/app thinks it has exclusive ownership of a local IndexedDB, and so might try to migrate the data in a non-atomic way at any time; where if other instances of the page/app are also running and accessing the same DB, they might blow up, or do the same thing and corrupt the DB.
(I've seen both of these in practice. In fact, I believe Reddit [in its new design] does the former; at around ~100 open Reddit tabs, they all crash! [I think it has something to do with their chat system.])
IMHO, any webpage that can't stand being open multiple times simultaneously is badly architected. Such pages have been "coddled" too long by browser vendors, by allowing devs to mostly disable the user's ability to easily open links as tabs. We should stop coddling these pages.
If we give users back the ability to easily open tabs on modern websites, we'll see the owners of these sites finally [probably begrudgingly] fix the problems that cause them to want to disable opening things in tabs in the first place.
Their intentions were good, but.. you don't know what devs are going to do. As long as they're following spec, let them. Users can vote with their wallet or eyeballs.
NB: I don't want to throw too much shade at Vivaldi. I reported it. They fixed it. Still my fav browser
This has especially been annoying when I have happened to use DuckDuckGo's image search instead of Google's or Bing's and instead of having opened ten tabs with links, I have ten tabs with a thumbnail in each ...
On the modern web, the menu is more reliable.
Click handlers however may stop working if there is even the smallest typo or error far away from the code.
It won't just be that one link. Everything stops working everywhere on the site.
Its modern replacement ASP .NET MVC works much more like traditional web frameworks.