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

I'm sure there are some devs who reach for a div because they're unaware of the proper way to disable submit behavior.

10 years ago someone decided that dragging links is so much more important than selecting text, selecting text is scarcely possible. I'm going to have to fork a browser to give link-dragging the demotion it deserves. It was probably those DIV guys.

Use elements as close to their original intention as possible

Another good example is bizarre error handling conventions when working in TypeScript. Claude will come up with tons of weird ways of doing this, using different approaches all over the place, but rarely consider simple patterns like 'return an expected value or an error'.

- why do you need to listen for events at the document level?

not that i disagree with the article, but some arguments didn’t seem right.

In my day job's shared library, we made a Clickable component that basically exists to abstract away the decision to use a button or an anchor tag, and resets the styles so both elements act the same way (both by default and when we apply styles to each).

We'd have a lot of confusion on the design side about button-as-design vs button-as-function and now we don't have to deal with that at all anymore.

And since the styling's been reset in a predictable way, it takes away one of the bigger reasons why people go to divs in the first place.

> One of the weirdest “debates” I seem to perpetually have with framework-enthusiastic developers is whether or not a <div> is “just as good” as a <button>.

How does one's desire to use a framework have any impact on their ability to recognize the usefulness of a button? Did I miss something? Is there some portion of any of the major framework documenation that suggests it's better to use divs instead of buttons?

> Among the React crowd, and also among people who seem to enjoy HTMX, I see a lot this…

Lol This has been a problem since way before React hit the scene. And people not using frameworks aren't magically immune to using divs instead of buttons.

The compiler and preprocessors are very picky about accessibility issues like these.

It was annoying in the beginning, but I tried to follow the rules it set out. It feels very professional, and I’m thankful for the guidance.

What’s annoying now is when my coworkers thinks I’m making things unnecessarily complicated by trying to follow these rules and guidelines. A <div> with an onclick is so easy compared to a <button> with extra styling and sometimes calling preventDefault().

But this is not a new problem or one "among the react crowd". Anecdotally I'd say it was more prevalent 10 or 15 years ago.

The web is darn simple, but we are the place where it is made extremely over engineered and expensive for both companies (salaries and 2-3x more staff needed than necessary because of the bloat) and users of their products (in terms of payloads).

And yet JS-heavy frameworks seems to have the best job market.

Everything seems to be upside down.

And here i am, wishing some would do just this. Especially creators of log in forms which make the “reveal password” button the next focus point instead of the “submit” button

Here's a tip for weirdo front-end devs that do this: You are not smarter than the people that created the spec.

Are you sure? Screen readers should be able to detect a div with a onclick as interactable, no? And if they can’t, that seems like an exceedingly simple fix. I’d be shocked if they can’t already detect onclick.

However, I was tweaking my app today, after having read this article, and realized I'm using some anchor-links as buttons just because I wanted them to be styled exactly like a link.

Then I tried adding role="button" and of course I couldn't tab over to my link-button. So I added tabindex="0", just like the article tells you not to do, and that allowed me to tab over to it but I still couldn't activate it with spacebar.

So I finally caved and Googled "how do I make a button look just like a link" which brought me to this article: https://piccalil.li/blog/link-button/

And now it behaves properly. Yay a11y.

Is this actually true nowadays? Given that advice like this is often parrotted by people who don't actually use screen-reading software, I sometimes wonder if this is a situation where we've just been saying this and repeating this advice; meanwhile, screen readers have obviously become sophisticated enough to recognize that a div with an onclick handler on it is probably, you know, clickable and interactive.

Stop implementing date pickers when <input type="date"> exists.

Stop implementing smooth scrolling. Browsers already do it on their own, and your implementation will not work. Really, just don't mess with scrolling in general. Don't make scrolling have "momentum". Don't change scroll speed. One site I've been to goes out of its way to change how much a scroll wheel click scrolls the page. For fuck's sake, can someone explain to me why that would be a feature!? Why go out of your way to override a specific user preference!?

All this bullshit changes expected behaviors, reduces accessibility, reduces the performance of your web page (and therefore increases CPU and battery usage)...for no reason whatsoever.

It has the "onclick" property set though. The other two points are pretty valid, however. It's a shame we don't have a proper "onsubmit" property or something like that. "Oninteract"?