[lyricaljoke]

My very similar pet peeve is about websites that use `onclick` handlers and similar to implement navigation. Just use a damn anchor tag, which gets you correct link behavior for free:

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

[Zak]

I've seen an increase in people doing this sort of thing over the past few years. I imagine it has something to do with frameworks and ignorance or apathy, but the old fashioned way almost always provides the best UX.

To anyone reading who has tried to get fancy with a substitute for the <a> tag, I wish you mild discomfort and inconvenience.

[philistine]

Could it be that the devs who write that code are not allowed to touch the CSS so they implement the visual functionality they want in their framework instead of telling the design team their intent?

[Zak]

There could be any number of weird constraints that would lead a developer who knows better to do such a thing in a specific situation, but someone designed (or failed to intentionally design) the system in question.

That person should sit alone in a room with no distractions and think about what they did.

[lewiscollard]

No, it is because a significant subset of React developers do not know how to write HTML.

[mrcsharp]

What's scary is that with proliferation of LLM-assisted code editors and vibe coding, and considering the training material for these models, this is only going to get worse and worse.

[3form]

These people clearly don't care for mild discomfort and inconvenience already...

[psygn89]

Yup. I think a lot of the devs that started with React jumped straight into the "fun" stuff without learning some of the "boring" fundamentals.

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.

[OptionOfT]

This reminds me of Microsoft's website checker in Office 365.

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.

[majewsky]

Shush! That's a feature to avoid the 10-second mandatory wait on intranet links that their safety checker cannot possibly reach. :)

[Akronymus]

Also, get rid of JS based scrolling. I scroll a lot with pressing the middle mouse button. Too many sites break that.

[Findecanor]

Sites that bind the arrow keys so I can't use them to scroll with.

[epidemian]

oh, 100% yes! The job project i joined somewhat recently is a moderately-complex React web app, and none of the navigation elements are actual links. Everything is done by onClick handling, even thought many things are, conceptually, just links. I have no idea why this kind of thing is so widespread on the web front-end world.

[zahlman]

We've reached the point, years ago even, where image hosting sites will not show you an image without JavaScript, even. Just use a damn img tag.

[warkdarrior]

If they link to the image directly, it makes it easier for users to share that link directly. We cannot have that, so instead we get a web page using exabytes of JS to show the image and a bunch of ads.

[derefr]

I wonder why browsers don't intercept JS-triggered navigation (or history.push) events that happen with a click handler on the stack — where it can be determined from the event data of that click handler that the user additionally used the middle mouse button or was holding cmd/ctrl at the time — and rewrite them into navigation-in-new-tab. (Ideally, without making the caller aware that anything different happened than what it was expecting.)

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!)

[yakshaving_jgt]

> it's exactly the semantics the user is expressing their desire to trigger.

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.

[8n4vidtmkvmk]

Vivaldi recently took liberty to "restore" a scrollbar to the body tag of my app even though I had intentionally moved it to an inner div. It royally effed up my app with no workaround.

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

[derefr]

Keep in mind that this check+logic would only come into play within the call to `history.push` or the `window.location.href` setter.

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.

[Findecanor]

I tend to open most links with a right click and then the first menu option: "Open link in new tab", and done so fast enough that I have not actually read the menu. But when the "link" is not a link but just an image, I have then instead clicked on "Open image in new tab".

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

[johntash]

In case you want to save a few seconds of your life, you can also middle click or ctrl click instead of right clicking + left clicking on the menu.

[Hemospectrum]

...Except on websites that override this to make those links open in the current tab, or just silently fail.

On the modern web, the menu is more reliable.

[econ]

You forget the most important part. When you inevitably screw up and break things it is nearly impossible to create enough garbage html to stop the anchor from doing its job.

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.

[tln]

Yes! If it's clickable, it should either be a button or a link.

[culi]

there are plenty of other vanilla html elements that are clickable. <details>, <input type=[button|checkbox|radio|file|etc]>, <label>, <select>, etc

[tln]

True although the built-in click behavior is sufficient on these, ie you should not need to add onclick. Which should be for <button> and <a>

[weaksauce]

when i was doing .net programming way back in the day asp.net handled each navigation with a javascript event and it broke all that stuff. this was right before ruby on rails existed so maybe it’s better now.

[alexjplant]

This was specific to Web Forms, a now-deprecated framework that did a lot of implicit state management that necessitated POSTing to the server with an encrypted client-side state called the ViewState.

Its modern replacement ASP .NET MVC works much more like traditional web frameworks.