I've been a professional C, Perl, PHP and Python developer.
I'm an ex-sysadmin from the late 20th century.
These days I do more Javascript and CSS and whatnot, and promote UX and accessibility.
If I want something to act like a button, I'll use a button.
I'm not sure that people think it's more difficult than using a div.
Using a div means you have to replicate all the features that button already provides. You have to reinvent the wheel. You can't have it act like a native button widget, with all the familiarity that invokes.
I don't think people use div because it's technically easier to implement - it's not - I think they use it because they haven't learned about button.
Cynically, if someone made a library called "newTrendyButton" and released it to the world and all it was was actually, you know, a straight-up HTML button, then I think people would use it, and when you listed its features they'd all be very impressed and write tweets about it.
Devices and browsers have their own systems - for example if you made your own select replacement and someone used it on iOS, they'd get a different experience to the one they get in native apps or on other websites. If you have a good reason for that, you can override the select element, but I honestly think the case for this is small.
Users see something that looks like a button and it behaves like a button. Developers see a button and it behaves like a button.
My argument is a pure speculation. We would never know the truth, unless we're gonna do big poll asking "Hey, do you know HTML supports buttons natively? If yes, why don't you use it?"
But from my experience, when I was less experienced, I tried to use semantic HTML and resorted to divs as soon as it didn't work as I would expect (because I know divs are working at least CSS-vice)
But this isn't really working. You are making some look the way you want, but by using a div you are:
Removing focus handling. A div isn't a native interactive component, so it doesn't receive focus, and won't have focus styles
Removing keyboard handling, so now all those users who rely on keyboard navigation are stuck
Remove any screen reader support. A screen reader can't announce the element as a button, can't convey what state it's in
I'm not really sure why anyone would reach for a div when form elements in HTML are so well known and have been in use for decades. As for styling, there are literally thousands of guides online to show how to do it, and plenty of ready-made solutions that even the laziest developer can copy/paste into their own websites.
But even in your example in this post, you're not showing the full picture, despite already using Javascript to modify the CSS of a button. What you're doing by removing the "quirks" is you're removing the very features of a button that people rely on to actually use the button.
You've removed the hover and focus styles, and left in a comment from the original React example that warns about making sure they get set correctly, but you don't do that. Focus styles are absolutely essential for those users who rely on keyboard for navigation. Try it yourself, visit a website and move around without a mouse. Notice how the visual focus indicator moves to each interactive element as you tab to it? Now imagine how difficult that navigation would be if there were no focus rings or borders on elements.
Never remove focus styles. You can change them if you feel you need something more in keeping with your design, but never remove them.
reset built-in styles of a button https://css-tricks.com/overriding-default-button-styles/
Don't forget to provide styles for:
- default state
- `:hover`
- `:active` (See also https://bugzilla.mozilla.org/show_bug.cgi?id=68851)
- `:disabled`
- `:focus-visible`
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I'm not sure I agree with your axioms.
If I want something to act like a button, I'll use a
button
.I'm not sure that people think it's more difficult than using a
div
.Using a
div
means you have to replicate all the features that button already provides. You have to reinvent the wheel. You can't have it act like a nativebutton
widget, with all the familiarity that invokes.I don't think people use
div
because it's technically easier to implement - it's not - I think they use it because they haven't learned aboutbutton
.Cynically, if someone made a library called "newTrendyButton" and released it to the world and all it was was actually, you know, a straight-up HTML button, then I think people would use it, and when you listed its features they'd all be very impressed and write tweets about it.
Devices and browsers have their own systems - for example if you made your own select replacement and someone used it on iOS, they'd get a different experience to the one they get in native apps or on other websites. If you have a good reason for that, you can override the select element, but I honestly think the case for this is small.
Users see something that looks like a button and it behaves like a button. Developers see a button and it behaves like a button.
My argument is a pure speculation. We would never know the truth, unless we're gonna do big poll asking "Hey, do you know HTML supports buttons natively? If yes, why don't you use it?"
But from my experience, when I was less experienced, I tried to use semantic HTML and resorted to divs as soon as it didn't work as I would expect (because I know divs are working at least CSS-vice)
But this isn't really working. You are making some look the way you want, but by using a div you are:
I'm not really sure why anyone would reach for a div when form elements in HTML are so well known and have been in use for decades. As for styling, there are literally thousands of guides online to show how to do it, and plenty of ready-made solutions that even the laziest developer can copy/paste into their own websites.
apparently it is not so wide knowledge, if you take a look around, there are plenty webiste using divs instead of button
There are even dedicated articles about it, for example web.dev/use-semantic-html/#use-but...
But even in your example in this post, you're not showing the full picture, despite already using Javascript to modify the CSS of a button. What you're doing by removing the "quirks" is you're removing the very features of a button that people rely on to actually use the button.
Not sure what you're talking about
You've removed the hover and focus styles, and left in a comment from the original React example that warns about making sure they get set correctly, but you don't do that. Focus styles are absolutely essential for those users who rely on keyboard for navigation. Try it yourself, visit a website and move around without a mouse. Notice how the visual focus indicator moves to each interactive element as you tab to it? Now imagine how difficult that navigation would be if there were no focus rings or borders on elements.
Never remove focus styles. You can change them if you feel you need something more in keeping with your design, but never remove them.
(Safari and IE require polyfill)
That is how CSS reset works - everything is removed, developer suppose to provide their own style
There is even a comment