No, but five, ten years ago that wasn't the average "junior web dev" outlook. There was diversity in experience and education.
Big money FAANG posts have really distilled the market down.
Maybe I'm just an oldfart. When I started a quarter of a century ago, people were crowing about Frontpage experience. I'm fairly sure I'd boasted about Macromedia Dreamweaver 3 expertise. And there was an explosion of technologies being thrown around between different devs. But now you don't get to discriminate against bad technology if the market demands it.
What's the beef with clickable divs? Are you referring to just the case where they're misused for top level navigation? Or more generically?
It's pretty common to not want the default behavior of an A tag, so instead of the e.preventDefault(); e.stopImmediatePropagation(); dance, a clickable div works great. Non deep-linked sub-nav (tabs, etc...) come to mind.
Or maybe I'm hooked into a router and I need to pass some additional state, or control a transition direction, or maybe I want a navigation to happen after some async action completes, etc...
Also, not all clicks are navigation actions.
BTW, I'm not a react guy, just vanilla web components here, but genuinely curious why you see clickable divs as a bad thing?
* Accessibility tools may not be able to detect that it's an interactive element unless you go out of your way to mark it up as such
* It often (always?) breaks middle-clicking/opening in a new tab. In your navigation example is fine, but for example in Jira it's an absolute crapshoot which links will behave properly when middle-clicked
* We already have a tag for a clickable element that is not a link: <button>
Good points, but I think you and the others who responded to my question are thinking about "web pages" vs what I generally create, which are responsive mobile PWAs for internal line of business apps.
> Accessibility tools
Not all applications are created for accessibility, it depends on the app and the intended audience. While in a perfect world we'd all be section 508 compliant, cash strapped startups frequently aren't in a position to invest in that for MVP.
> It often ... breaks middle-clicking
Do you use the same standard for a native app that you install from an app store? Almost everything I've written over the past decade or so has been "web tech as a replacement for native" - not a public web site, so the function comparison should be against native apps. I probably should have mentioned that in my original question.
> We already have a tag for a clickable element that is not a link: <button>
Sure, but I don't think it always makes sense semantically or from a code standpoint to use the button tag. For example, maybe I have a tiny little plus symbol for "expand". Like a lot of folks, I generally use some like font icons, or material symbols for stuff like that. Frequently it makes more sense to use a span or div to render the icon, and just handle the click event.
I'm not advocating for the use of divs instead of "a" tags everywhere, I just think there are normal and reasonable situations where it makes sense.
All engineering is a series of compromises and trade-offs. I'm not going to judge a dev that makes an info icon work to slide out a drawer which has a tabbed sub-nav, because they didn't hammer an A tag into something that it wasn't intended for, or because they didn't want to try to make whatever font icon library they're using work with a button tag.
Do you religiously check that you haven't broken ctl-click, middle click or "right click/open in new tab"? I come across a site - sorry I meant "app" - almost every day that breaks this.
There's nothing wrong with clickable divs. The problem is using them in place of links.
If you're linking to something, then just use a link. So people get their accessibility/screenreader support, and you can still use JS to accomplish whatever other auxillary behavior you want.
