6 ms·

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

> 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.
znort_ 1y ago
> 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.
jmull 1y ago
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.?
- culi 1y ago
  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
Sohcahtoa82 1y ago
> Using a DIV means you start from empty plate When comparing to a Button, that's a bug, not a feature.
cferdinandi 1y ago
No. Objectively no. It is INFINITELY easier to add type="button" than all of the other shit I mentioned in my article.
- galaxyLogic 1y ago
  Just curious, what does it mean for something to be "infinitely easier" than something else? :-)
serial_dev 1y ago
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?
- brazukadev 1y ago
  React in a nutshell
- Levitz 1y ago
  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.
  - dpark 1y ago
    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.
    - Levitz 1y ago
      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.
      - dpark 1y ago
        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.
Mawr 1y ago
> 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.

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.

znort_ 1y ago

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

jmull 1y ago

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

culi 1y ago
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

Sohcahtoa82 1y ago

> Using a DIV means you start from empty plate When comparing to a Button, that's a bug, not a feature.

cferdinandi 1y ago

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

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

serial_dev 1y ago

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?

brazukadev 1y ago
React in a nutshell
Levitz 1y ago
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.
- dpark 1y ago
  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.
  - Levitz 1y ago
    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.
    - dpark 1y ago
      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.

Mawr 1y ago

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