Does type="button" go with button, or is that not needed in this instance?

I’ve been seeing it used with an audio button, and I have seen it not being used.

Does type="button" go with button, or is that not needed here?

<button type="button" id="button" >Play / Pause</button>

or, would it only be used if input was being used?

On here it shows type=button" being used with button.

But I don’t know if it is appropriate or the right usage of it being used there.

https://codepen.io/lol24899/pen/aPZvXK

If you look a bit further you will find your answer.

I’m confused because in this example they show, type="button" is being used without the form element.

<button name="favorite" type="button">
  <svg aria-hidden="true" viewBox="0 0 10 10"><path d="M7 9L5 8 3 9V6L1 4h3l1-3 1 3h3L7 6z"/></svg>
  Add to favorites
</button>

What does the MDN documentation that TechnoBear linked to say under Attributes - type about the possible values?

1 Like

So, type="button" only gets used when?

type
The type of the button. Possible values are:

submit: The button submits the form data to the server. This is the default if the attribute is not specified, or if the attribute is dynamically changed to an empty or invalid value.
reset: The button resets all the controls to their initial values.
button: The button has no default behavior. It can have client-side scripts associated with the element’s events, which are triggered when the events occur.

Seems pretty obvious that it would be when you’re using a button to do something other than submit a form.

1 Like

Add the attribute type="button" to <button> elements, unless the button submits a form, in which case you use type="submit"

Which would mean, it would be added on here:

Which is right ?

<button type="button" id="button" >Play / Pause</button>

The answer is “it depends”. Depends on what? On whether or not you think it is the best choice to use.

OK, maybe that isn’t the most helpful. Look at it this way. Not considering having a click event on something else and limiting your choice to either

  • <input type="button">
  • <button type="button">

ask yourself questions.

  • Is it OK that the button relies on JavaScript?
  • Do I want to use CSS to apply styles that would be easier with a button compared to an input?

Hi there asasass,

  1. if the button is contained by a form element
 <form action="#">
  <button type="button">do something other than submit</button>
 </form>

…and you do not want it to submit the form, give it the type=“button” attribute.

  1. If the button is contained by a form element
 <form action="#">
  <button>submit</button>
 </form>

…and you want it to submit the form then it does not need an attribute, but
you could use the type=“submit” attribute for clarity’s sake.

  1. If the button is not contained by a form element

  <button>do anything</button>

…it does not require the type=“button” attribute as it is the default value
outside the form.

coothead

3 Likes

Thank you for explaining that to me.

How come in this example they provide, button is not contained by a ‘form element’
Yet, type=“button” is still being used there. How come?

<button name="favorite" type="button">
  <svg aria-hidden="true" viewBox="0 0 10 10"><path d="M7 9L5 8 3 9V6L1 4h3l1-3 1 3h3L7 6z"/></svg>
  Add to favorites
</button>

Hi there asasass.

if the button element is not contained by a form element,
it does not require the type=“button” attribute.

If “they” have included it, then they either don’t know that it
is the button’s default type, or they have included it for some
other reason that “they” believe makes it necessary.

What that other reason could be, God only knows ! :rofl:

coothead

1 Like

Or maybe they used it for “clarity’s sake”…

I think that should read as…

Or maybe they used it for “clarity’s sake”. :rofl:

coothead

1 Like

That is only an example, it’s focus is to demonstrate Accessibility concerns. It shows only enough of a snippet needed for that goal. It does not include different contexts in which <button> might be used. You will find that much documentation is “trimmed down” so that what is being documented will be easier to understand. Showing full examples of all possible use cases would be difficult if not impossible. i.e. documentation is not meant to be for a copy / paste (although that can sometimes be a good starting point to experiment with to self-test your understanding).

A trade off is that often newbies will see examples not as examples but as “rules” and / or not realize that other things can be / should also be done. eg. security and accessibility come to mind.

4 Likes

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.