Just use a button

> they're unaware of the proper way to disable submit behavior.

That is an issue in favor of DIV, you don't accidentally set type="submit" because you don't know about that. There are many things many people don't know.

Using a DIV means you start from empty plate and explicitly add the features you want to add, which makes it easy to later remove or change those features when you want to.

Of course if your knowledge of HTML standards is great and Button exactly fits your current use-case you probably will use it, but designs and requirements change all the time.

Using DIV makes your design more transparent, you see there are certain features you have set to it by adding the attributes.

Using a Button means you (and other people reading your code) probably want to consult documentation to understand what it exactly does. With a DIV + attributes that is explicitly "spelled out".

Just some pros and cons.

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

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.

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.

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

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

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

No. Objectively no.

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

Agreed. It's not hard and it's definitely not unreasonable to expect front-end developers to know the very basics of semantic HTML and accessibility standards. It's literally their jobs

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?

React in a nutshell

> 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, but they can reimplement it in a good enough state for the vast majority of users without getting bothered by default behaviour or styling that might vary per browser.

Which, don't get me wrong, is still a problem, accessibility matters, but if there's a reason as to why something happens, the way to fix it is to actually look at that reason.

A button can easily be styled and it’s definitely easier to fix the one little behavior than to reimplement all the other behaviors that are needed.

Just curious, what does it mean for something to be "infinitely easier" than something else? :-)

And yet often this is not what happens. Why?

People don't do stuff poorly on purpose. There's also nobody out there for which button elements are some arcane and obscure thing, we all know they exist, so what is happening?

I'm not arguing for using divs instead of buttons, I'm arguing that if that happens there's a reason for it, and we ought to look at that reason and attempt to deal with it rather than admonishing developers in general.

Does it happen often? The unintended behavior seems extremely discoverable. “Hey, Google. Why does my button onclick not fire correctly?” “Oh, I need to set this stupid property.”

Would it be nice if this wasn’t necessary? Sure. But browsers aren’t going to break compatibility to fix this quirk.

> we ought to look at that reason and attempt to deal with it

I’m curious how you think we could deal with this aside from education.