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?

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.

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

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.

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

I don't think it skips the handler behavior on default but can't check now

It's the default for buttons inside forms, but it's SO trivial to add type="button" than any argument that div's are a better choice because of this should be dismissed as unserious trolling out-of-hand.

Nope, it's the default:

https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...

Maybe you’re thinking of <input type=“button”>, which doesn’t submit?

I seem to recall that once upon a time the default type for a button was in fact "button" but at some point (somewhere in the region of html 5 / es6) it was switched into "submit".

You always want all the accessibility features. If your button is a button, then you want the whole lot: the correct role, tabability, keyboards shortcuts, everything. There is no situation where you only want some of those features.

So if you use a div, you _always_ need to add _all_ of the features. Whereas if you use a button, you usually need to remember to add the correct "type" attribute (although if you're building a form, you might not even need that).

You also mention transparency. A button makes your design transparent: it is a standard element, and web developers should know what it does. A div is not transparent - firstly, if I'm a developer reading that code, I need to look at context clues to understand what the authors' intent was (a tabbable element with a keydown handler and a click handler could be all sorts of elements, not just a button, so now I need to inspect event handlers and see what they do), and secondly, many people do not implement this stuff correctly, so what you're usually looking at is something that looks like it might have been intended as a button, but is missing a bunch of features. Was that intentional or did the author just forget some stuff?

This isn't really a "pros and cons" type of thing. Just use a button. It's doing all the work that you'd have to do manually, but automatically. Just use it.

So some developers cannot be trusted to figure out that they, in some cases, need to add a single attribute to the button, but they can reimplement a button with all its behavior, feel, look, and accessibility settings starting with a div?

DIV isn't a button with features disabled. DIV is something else entirely, and you have to emulate most of the features in Javascript, badly. As the original article explains...

How is it harder to learn “want normal button” => <button type=“button”…> than “want normal button” => <div role=“button” tabindex=“0”…>, plus the javascript for keyboard access (plus css for at least the cursor), etc.?

> Using a DIV means you start from empty plate and explicitly add the features you want to add,

Yep, which guarantees you will not add everything that's required for e.g. accessibility. It's not realistic for every single dev to be aware of every single important property of a button. This approach just doesn't scale.

No. Objectively no.

It is INFINITELY easier to add type="button" than all of the other shit I mentioned in my article.

Every input should have a type. It's a good thing to put in a linter and run before you consider your code complete.

Yes, the default is bad, but you should be overriding every one of those anyway.

> Using a DIV means you start from empty plate

When comparing to a Button, that's a bug, not a feature.

> Of course if your knowledge of HTML standards is great and Button exactly fits your current use-case you probably will use it

i would have imagined that coding html should be done by people with basic understanding of it, at the bare minumum to know what a button is. but maybe that's just me being old and not going on with the vibes ... maybe i'm just going to facepalm a bit and get some fresh air.

When IE died I thought for sure the path was clear for highly styleable form elements and tables with all the features that countless third-party libraries have re-implemented for every new UI framework that comes out. Now I don't think we're going to get there before I die.

I heard it almost a decade ago in Polymer and Web components circles https://www.polymer-project.org/blog/2016-05-26-IO-2016-Reca...

It’s strange to look back and see that most spa projects still just bundle it all up into a gigantic js file…

> I vaguely remember, back in 2010, when I wrote my app, you couldn't style a button consistently across all browsers. They were grey boxes in firebox, or used other OS standard styling.

I'm sure I'll trigger a lot of designers by saying this, but I'm probably not alone in valuing basic usability FAR above styling. I much rather have an ugly button that looks like 90's era Tcl/TK than something pretty that doesn't behave like I expect it to.

As an end user: I chose my web browser. I know how things tend to look in it. I know that this is not the same as how they look by default in other browsers. I do not care. I actively want it the widgets to look familiar, because that means I can readily parse the UI, and don't have to think about your design.

I actively do not want you to even try to "make it look the same everywhere", because the way you want it to look will in general be a way that degrades functionality for me. When you try, you send the message that you know better than me about how I want the GUI on my computer to work; and that makes me less inclined to use your site, and thus your product.

The great thing about using a platform as big as the web, which runs on a million different types of devices, is you can say "not my problem" and offload it to someone else.

When you're building a webpage or webapp, you're really building, like, 5% of an app. The other 95% is taken care of for you. You can always just say "fuck it, who cares if the button is gray in Firefox". Because you know what? Firefox might just fix it. And boom, you get the same result with no effort and no maintenance burden. And even if you don't, who cares? Maybe Firefox users like that and that's why they're on Firefox. All you need to know, as a web developer, is that the button does clicky things and is a button. That is a super power. We should use it!

Holy fsck! 30 years on the web and today I learn about this Alt/Option trick. Thank you!

Android works great - lets you select the # and then gives you a context menu with the option to call (or copy, or search).

...unless someone made the phone # a tel: protocol link, in which case it has the selection behavior of any other link. Which is mostly fine, since "copy" is a context menu option for tel: links... unless some jerk put a tel: URL in that isn't the same number as what is shown in the text of the link, in which case it's time for some crazy hoop-jumping to either copy OR call the number.

are css resets not in vogue any more? I still use them for all my side projects. As well as a normalize.css[0] that smooths over any additional browser inconsistencies. The original Meyer reset is definitely overkill, but there are a couple newer more minimal ones out there[2][3]

[0] https://necolas.github.io/normalize.css/

[1] https://meyerweb.com/eric/tools/css/reset/

[2] https://www.joshwcomeau.com/css/custom-css-reset/

[3] https://piccalil.li/blog/a-more-modern-css-reset/

Search engines were also only good at looking up things, not software engineering. I find it a blessing that a human is still valuable in this process we call software engineering. And meanwhile you can use search engines just like LLMs to learn and discover much faster than without them.

Is is not okay to wrap a link inside a button ? I guess not

Which elements are allowed to wrap which is unclear to me

Well it might be a SPA so it's not a real link but rather just a function call + pushing some stuff to history and updating the URL (if you're lucky!)

This comes from either business or the UX people who want stuff to look pixel perfect to their stupid wireframe.

Why does a website that sells to a pretty much captive audience who cares more about functionality than looks obsess so much about every single button looking pixel perfect to some arbitrary wireframe, I will never know.

> You can click on those "folders" to expand/collapse them, and it's implemented as a <div> with

... Isn't that what <details> and <summary> are for?

what's annoying about that example is that all of those <div>s could be buttons with no other changes. The only content inside the button <div> is the title and folder icon, not the list of examples associated with that title. That's just fine for a button!

The other thing I'd do is add `aria-controls=folder0` to the button that toggles visibility of the list with `id=folder0`

I too have encountered this reasoning.

Then I write some basic CSS and show them they have nothing to fear.

Yet, I still remain irritated beyond belief that its such a common thing. In 2025. Hell, in 2017!

I don't know what to do about it, other than constantly remind people about things, but it gets tiring.

Though, its a great interview question. Its a quick way to understand if someone knows the fundamentals or not.

Kinda like how people got ".bind" wrong on functions for years.

That's the same behavior as a <button> without tabindex, like the author is proposing.

It's generally advised not to set tabindex to anything but 0 or -1 and let the document order dictate tab order.

I'm saying tabindex=0 is naturally sorted wrt other naturally focusable elements. That matches the behavior of the <button> you're trying to emulate. I don't know what tabindex>0 has to do with this.

See this fiddle https://jsfiddle.net/483uqjnp/

(again, I do not condone building your own <button>, just pointing this out)

tabindex=0 does sort naturally into the automatic tabindex order.

> So you are jumping through all the other tabindex elements

This part is correct (for elements with an explicit positive tabindex), which is why specifying an explicit positive tabindex is considered a code smell. If you don’t specify a tabindex on an element that’s focusable by default, it behaves like tabindex=0.

Try it:

  data:text/html,<button>foo</button><i tabindex=0>bar</i><button>baz</button>

This is incorrect. https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...

Not sure about that, MDN's example shows keydown being attached to an element.

https://developer.mozilla.org/en-US/docs/Web/API/Element/key...

Hi, good premise overall, but there are just a lot of little things that are off.

- It only counts as "fucking with tabindex" if you give it a value that's not 0 or -1. You should give that specific disclaimer, because there are uses for tabindex=0 other than reimplementing <button>.

- Divs can definitely receive keydown events. If I go to an arbitrary web page, pick a div and run `div.tabIndex = 0;` + `div.addEventListener('keydown', console.log);`, I see those events coming through when I have the div keyboard-focused.

- "Run your code, somehow..." I think just calling `notRealBtn.click()` is the best option.

- Stupid but semi-interesting nitpick: 'keydown' is good for enter, but you should be listening to 'keyup' for the space bar. That's how real <button>s work anyway.

- The 'keyup' listener should call event.preventDefault() to prevent the default behavior of the space bar scrolling the page.

> Not events generally, keydown events specifically, which do not fire on child elements of the document.

Are you sure? I have a 17 year old HTML tool written using plain, vanilla JavaScript where keydown on a child element seems to have been working as expected.

https://susam.net/quickqwerty.html

https://github.com/susam/quickqwerty/blob/1.2.0/quickqwerty....

Nice article, by the way!

In today's world, yes. But as with a LOT of complaints about "web developers!!!!" the answer is usually "because of the way the web WAS."

Before IE became Edge (and maybe even in the earliest versions of Edge), there were certain styles and descendants that simply did not work on a <button> element, like Flexbox and Grid positioning. So, if your button had content like an icon, and you were trying to align it a certain way with the label, you simply couldn't use some features of CSS like you could with a <div>. It was a pain in the ass.

In the same vein, do you remember the period where some browsers wouldn't allow you to make a button look like a link using CSS, because they thought it might deceive people and thus be a security issue? I do.

And similarly when people complain about the complexities of webpack and bundlers in general, do you remember including the jQuery <script> tag on the page and then almost always needing to call `jQuery.noConflict()`? And how in those days, most people got even THAT wrong, because atomic <script async onload> behavior didn't work correctly in all browsers yet, so other code could actually run in between a <script> and its onload callback, meaning the jQuery.noConflict call was ineffective and something else could steal it? I remember. webpack fixed that by automatically scoping everything.

Nowadays, a lot of those workarounds are unnecessary (depends what browsers you're supporting). But it's not like there was never a reason for them.

>is pressing tab twice instead of a single time really that big of an issue?

When you expect to press once, and end up doing the wrong thing because of that incorrect assumption, absolutely yes.

Having to think about it, at all, is the annoying part. Thinking == Anxiety.

Also a click handler on a div isn't going to do much for someone who isn't using a mouse, which would include a lot of screen reader users.

All of those seem like examples of things you’d want your screen reader to tell you about.

It's worth noting that VoiceOver is well-known for being a lot more lax than most other screen readers. Other options tend to be a lot more strict around standards and what they'll announce.

Yeah I don't want to work with lazy people either. Shame.

No I haven't tested it, that's what I'm asking.

This piece of advice, to me, just feels like a piece of advice constantly repeated by a bunch of people, none of whom actually use the software for which the piece of advice is meant to benefit. That scares me; like we've all lost touch with the ground truth on this one; I'd love to re-sync with it, that's what I'm trying to do, I just don't have the first clue how to do it.

> This still has issues in some browsers.

Your knowledge is out of date. <input type="date"> been implemented in nearly every browser since 2018, with the exception of Safari which was slow and didn't put it in until 2021, and Opera Mini which still doesn't have it at all, but who the hell uses Opera Mini?

https://caniuse.com/input-datetime