6 ms·

A good addition to this article is that most buttons should have type="button" on them. By default, buttons are type="submit", which if contained inside a form

A good addition to this article is that most buttons should have type="button" on them. By default, buttons are type="submit", which if contained inside a form will submit that form. I'm sure there are some devs who reach for a div because they're unaware of the proper way to disable submit behavior.

mixmastamyk 1y ago
Believe that default is for <input type="submit">, not <button>.
- pverheggen 1y ago
  Nope, it's the default: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/button#type https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/... Maybe you’re thinking of <input type=“button”>, which doesn’t submit?
- cferdinandi 1y ago
  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.
- tomkarho 1y ago
  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".
  - pwdisswordfishy 1y ago
    The nice thing about actually versioning standards (instead of doing that lazy "living standard" shit) is that you can actually look such things up. https://www.w3.org/TR/html4/interact/forms.html#adef-type-BUTTON https://www.w3.org/TR/html4/interact/forms.html#adef-type-BU...
rado 1y ago
Right. I learned it the hard way lol
galaxyLogic 1y ago
> 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.
- thyristan 1y ago
  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...
- marcosdumay 1y ago
  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.
  - phatskat 1y ago
    > but you should be overriding every one of those anyway. I’m gonna be a bit of a pedant here, but button has 15 attributes. I feel like overriding every attribute on every element (or even just form controls) would make the people who complain about Tailwind classes being too verbose have an aneurysm
- MrJohz 1y ago
  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.
sam_lowry_ 1y ago
Indeed this long rant by OP misses the critical info. A button of default type will do weird things, IIRC it will skip the JS handler onCick, for instance.
- efilife 1y ago
  I don't think it skips the handler behavior on default but can't check now
  - Shog9 1y ago
    It does not. What it does do is submit the form, so if you trigger some fast change to the page or async behavior from the click event, you may never see it because the submission happens and the page reloads (or a different page loads if form action is set to a different URL). If you're relying on event bubbling, the click handler may run after the form is submitted, which is even less likely to do what you intend. If you aren't expecting this (and don't know how to discover it e.g. by examining browser dev tools, server logs, etc.) then you'll assume the button is broken and... probably try something else. Even if you do discover it, you may try something that won't quite have the same reliability - at one point it was common to see folks putting preventDefault() or return false in their click handlers to squelch the (correct) behavior, rather than changing the type of button.
    - sam_lowry_ 1y ago
      Yes, you are right. Thanks for the lengthy explanation.

mixmastamyk 1y ago

Believe that default is for <input type="submit">, not <button>.

pverheggen 1y ago
Nope, it's the default: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/button#type https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/... Maybe you’re thinking of <input type=“button”>, which doesn’t submit?
cferdinandi 1y ago
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.
tomkarho 1y ago
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".
- pwdisswordfishy 1y ago
  The nice thing about actually versioning standards (instead of doing that lazy "living standard" shit) is that you can actually look such things up. https://www.w3.org/TR/html4/interact/forms.html#adef-type-BUTTON https://www.w3.org/TR/html4/interact/forms.html#adef-type-BU...

rado 1y ago

Right. I learned it the hard way lol

galaxyLogic 1y ago

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

thyristan 1y ago
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...
marcosdumay 1y ago
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.
- phatskat 1y ago
  > but you should be overriding every one of those anyway. I’m gonna be a bit of a pedant here, but button has 15 attributes. I feel like overriding every attribute on every element (or even just form controls) would make the people who complain about Tailwind classes being too verbose have an aneurysm
MrJohz 1y ago
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.

sam_lowry_ 1y ago

Indeed this long rant by OP misses the critical info. A button of default type will do weird things, IIRC it will skip the JS handler onCick, for instance.

efilife 1y ago
I don't think it skips the handler behavior on default but can't check now
- Shog9 1y ago
  It does not. What it does do is submit the form, so if you trigger some fast change to the page or async behavior from the click event, you may never see it because the submission happens and the page reloads (or a different page loads if form action is set to a different URL). If you're relying on event bubbling, the click handler may run after the form is submitted, which is even less likely to do what you intend. If you aren't expecting this (and don't know how to discover it e.g. by examining browser dev tools, server logs, etc.) then you'll assume the button is broken and... probably try something else. Even if you do discover it, you may try something that won't quite have the same reliability - at one point it was common to see folks putting preventDefault() or return false in their click handlers to squelch the (correct) behavior, rather than changing the type of button.
  - sam_lowry_ 1y ago
    Yes, you are right. Thanks for the lengthy explanation.