While you do not need to provide the type attribute, I do this to clarify its intended behavior.
It has an effect. If you omit type="button" and the button is inside of a form, it will act as submit button.
(I say nearly because there are some subtle differences between the two elements. Most notable is that links typically have different cursors than buttons.)
You can and should make the cursor behavior identical with CSS.
You can and should make the cursor behavior identical with CSS.
I’ve never been a huge fan of buttons using cursor: pointer on the web. It runs contrary to how UIs work on all desktop platforms, where buttons do not in fact change the cursor to a hand.
At first I thought that the pointer cursor was meant to indicate navigating to a different page, but it seems like web design practices perverted this into “clicking this will perform any arbitrary action, which may take you to another page, but may also not do that.”
For me it depends. It feels pretty natural on websites, but feels off in web apps (Spotify or Figma come to mind; they default to cursor: default on interactive elements pretty heavily.) In web apps a pointer cursor feels like it should always perform an action on a single click—similar to how this is handled in file browsers when switching between single- and double-click-to-open mode.
Along these lines, the Lobsters codebase is cleaning up old href=”#” links if anyone wants to help. I largely agree with this post, but it would it would be a ton of visual noise to have a row of <button> tags across the top of our comments. I dunno. Maybe a proper designer could find a middle path.
It would be a good addition, could you add it to the GH issue? It doesn’t set the POST/PATCH/DELETE verb, though, so we’ll still need JS to avoid CSRF.
The dedicated “submit” and “reset” buttons are for specific form actions. Regular buttons are for (JavaScript) actions.
I guess I now officially belong to the group refered to as old developers.
Using JavaScript to hijack the click event of an element that has built in functionality is now the regular case.
An important corollary to this is do not use links within forms for things that should be form elements. I have hosted ecommerce web sites where the product search form was expressed as HTML links. So you might be looking at /widgets and there would be a list of (apparent) checkboxes that are actually links to
/widgets?color=red
and
/widgets?color=blue
to narrow your search by color. Then if you click one of those, you can choose between
/widgets?color=blue&size=small
or
/widgets?color=blue&size=large
It doesn’t really take that many options before google/bing/yandex/etc will be following links until the heat death of the universe before they exhaust every possible combo.
Don’t use links to represent form fields either, or your site will just be feeding a random combos of options to a bot army 24x7.
It has an effect. If you omit
type="button"and the button is inside of a form, it will act as submit button.You can and should make the cursor behavior identical with CSS.
I’ve never been a huge fan of buttons using
cursor: pointeron the web. It runs contrary to how UIs work on all desktop platforms, where buttons do not in fact change the cursor to a hand.At first I thought that the
pointercursor was meant to indicate navigating to a different page, but it seems like web design practices perverted this into “clicking this will perform any arbitrary action, which may take you to another page, but may also not do that.”I’ve seen it enough now that not having
cursor: pointeron a button feels off to me.For me it depends. It feels pretty natural on websites, but feels off in web apps (Spotify or Figma come to mind; they default to
cursor: defaulton interactive elements pretty heavily.) In web apps apointercursor feels like it should always perform an action on a single click—similar to how this is handled in file browsers when switching between single- and double-click-to-open mode.The Post button on this comment box has a hand cursor.
Along these lines, the Lobsters codebase is cleaning up old href=”#” links if anyone wants to help. I largely agree with this post, but it would it would be a ton of visual noise to have a row of
<button>tags across the top of our comments. I dunno. Maybe a proper designer could find a middle path.The
<button>tag can still be used and styled to look exactly like the link does today. So instead ofYou would have
Why not just use
role=button?It would be a good addition, could you add it to the GH issue? It doesn’t set the POST/PATCH/DELETE verb, though, so we’ll still need JS to avoid CSRF.
No. I want to reduce my usage of Microsoft products.
I guess I now officially belong to the group refered to as old developers. Using JavaScript to hijack the click event of an element that has built in functionality is now the regular case.
An important corollary to this is do not use links within forms for things that should be form elements. I have hosted ecommerce web sites where the product search form was expressed as HTML links. So you might be looking at /widgets and there would be a list of (apparent) checkboxes that are actually links to
/widgets?color=red
and
/widgets?color=blue
to narrow your search by color. Then if you click one of those, you can choose between
/widgets?color=blue&size=small
or
/widgets?color=blue&size=large
It doesn’t really take that many options before google/bing/yandex/etc will be following links until the heat death of the universe before they exhaust every possible combo.
Don’t use links to represent form fields either, or your site will just be feeding a random combos of options to a bot army 24x7.