What is the difference between <button> and <input type="button">

HTML-CSS
1

What is the difference and when to choose which one?

2

no difference. <button> is a new feature that came with html5 and is just a shorter way to add buttons

3

@smarpan From my understanding at a pretty basic level the <button> will automatically submit, which can cause problems if you want to use a button in a form without it submitting. So it might be better to use <input type="button"> or <button type="button">. Without a type, button automatically receives a type of submit.

Check this out if you want a more in-depth reason Button vs Input

1 Like
4

The <button> tag defines a clickable button.

Inside a <button> element you can put content, like text or images. This is the difference between this element and buttons created with the <input> element.

5

The main difference, besides the ability to add content inside the button element, is the default behavior.

The input element with a type of button has no default behavior, whereas the button element default behavior is to submit. That is, the button type attribute defaults to submit. This only makes a difference if the button is either using the form attribute(HTML5) set to a forms id or if the button is nested inside a form element.

I believe whether the button is used with, or without a form, the best practice today is to use the button element (which BTW is not HTML5).

1 Like
6

I prefer links over buttons.

7

@kerafyrm02 Yeah you can do that but buttons are more flexible in design. Links are just words but buttons can be styled with colors, effects, sizes, shapes, and can be more appealing at times. They are also easier to notice at times also not all buttons are used for leading to something else like a web page, consider the buttons on this page alone there are a lot of different uses for buttons that should be taken into consideration when making a decision.

1 Like
8

I also asked the same question, but <input> is for when you want somebody to put in some information like if you want someone to rate a program at one to five stars or put their name or email in.
<button> is for other stuff like turning on a switch or pressing the submit button or turning on an interaction. hope that helps :slight_smile:

9

More flexible in design? Give one example what a button’s design can do that a link design can’t?

All the buttons on this page could be links. Links contribute to SEO and buttons do not.

<form id="myForm" method="post">
     <input type="text" name="first">
     <input type="text" name="last">
     <a href="#" id="submit">Submit</a>
</form>

<script>
(function(){

    const submit = document.getElementById("submit");
    submit.addEventListener("click", function(e){
          e.preventDefault();
          this.parentNode.submit();
    });

})();
</script>
10

I agree with the design part of it, but there are other considerations as well, like semantics and accessibility.

This article has a bunch of links on the subject. I’m not saying I have particularly strong opinions on this but it is worth keeping in mind.

1 Like
11

Again., give me one example of a button’s design can have which a link cannot…

1 Like
12

Perhaps I wasn’t very clear. I meant that I agree with what you said about design. I just wanted to point out there are other considerations, besides the design.

1 Like
13

@kerafyrm02 Well if you consider accessibility users links won’t work the same for them as a button will even if you style it like a button. It also has a preset form that can be styled which makes it a little easier to work with.
Also links <a> are meant to be redirected to a different place of the same page or a totally different page so if your using them and not redirecting you are failing to use it properly. Of course you can style anything to look anyway with CSS but links are meant to be seen as words that can be clicked on and redirected.

I didn’t say they couldn’t be styled the same I said, they’re “More flexible in design?” because it’s easier too style a button to a certain look than it is to get the link to that same look. But for that matter you can just use a <div> and style it the same way.

My point is that they are similar but different in programming there are many cases like this but there are reasons they both exist.
Check this link if you want to understand in more detail I highly recommend it. and yes this is a link <a>

2 Likes
14

I guess it’s too hard to give a specific example. I also have no idea what you mean by it’s “more flexible in design”. That makes absolutely no sense to me.

Linking me a page that was created 5 years ago doesn’t really tell me much. Nor does generalization of terms.

As for accessibility, again, I have no idea what you’re talking about. I need specific examples.

15

I don’t care about the topic but, just a bit more info. Regardless of when the linked page was made, the whole thing talks about “why not use a div or link”. Specifically the conclusion sums it up pretty succinctly. But, I’m sure you don’t want to go there because @Myles2 already tried that so, I’ll quote here…

"Why Name, State, Role, and Value are important

What? You mean 1600 words later it isn’t obvious? OK, here goes. When people talk about many of the requirements for web accessibility, they’re really talking about Name, State, Role, and Value.

  • Alt text for images? The alt becomes the accessible name for the image object.
  • Providing explicit form labels? The label becomes the accessible name for the associated form field object
  • Keyboard accessibility? A lot of that has to do with Role and State of the actionable objects.
  • Advice against using DIV or SPAN as a button (or any other form control for that matter)? That’s pretty much all four – Name, State, Role, and Value (or lack thereof in the case of DIV and SPAN).

Many of the accessibility violations relating to the use of client-side scripting are mostly due to not properly managing Name, State, Role, and Value information of custom controls. You can (and should) avoid these problems by first opting to use HTML’s standard elements and attributes in the manner in which they were intended. For instance, a BUTTON Element already has a number of methods and properties available to it that you’re likely to forget about (or skip altogether) if you were to make one out of a <DIV> and bind some events to it. Can you use WAI-ARIA? Sure, but why? You’d still have to handle reacting to both keypress and click events, ensuring the item is in the tab order, and indicating the role. If you want to disable the button, you’d have to script that and ultimately you’re doing a whole bunch of work you don’t need to because using the right element for the job means accessibility is free. WAI-ARIA is best used to bridge gaps where the desired type of object or interactivity isn’t available in already existing core functionality or that core functionality isn’t yet broadly supported by browsers." end quote

It’s because functionally they can be created to do the same thing but, the only things that are treated like buttons with accessibility apps are buttons.

EXAMPLE FROM THE REAL WORLD
If a user who needs to use speech as their only input method says, “next button,” it will never get them to the link that you’ve made to emulate the look and function of a button, regardless of it’s name, appearance, id, class, etc.
Same with a user that has to blow in a straw twice for the next button. No amount of blowing will get them to that link, unless they view page source, realize someone coded it as a link that looks like a button, for fun. That’s the only way they’d know to use the command for “select link”. Most users, accessibility issues aside, won’t look at page source. I wouldn’t think that requiring users with accessibility to look at page source to find out how to use a page is best practice. Most accessibility users would just assume the button is broken and move on or email support about a broken button. That’s if they don’t sue you for making it harder for disabled people to use your page because you prefer links. Unfortunately, users don’t care how it’s coded, as long as it works as expected.

1 Like
16

Of course, this has nothing to do with the OP. :stuck_out_tongue_winking_eye:
more conclusion from linked pages

How to choose between a link and a button

Now we’re left with links and buttons. How do we choose between the two? Quite simply, by answering one question: What will happen when the user activates this control? The Microsoft User Interface Interaction Guidelines discussions of buttons and linksoutline this decision-making process rather well (paraphrased here):

  1. Will this control be used to initiate an immediate action?
  2. Is the action to navigate to another page?

Elsewhere they outline some general guidelines on making the choice:

  • Use command buttons for:
    • Primary commands.
    • Displaying windows used to gather input or making choices, even if they are secondary commands.
    • Destructive or irreversible actions, as well as commitment within wizards and page flows.
  • Use links for navigation to another page, window, or Help topic; display definitions; and command menus.

Whether or not you’re a Windows, Mac, or Linux person, these UI paradigms are the de-facto standard for link and button controls across all operating systems.

  • A button initiates an immediate action, such as form submission.
  • A link triggers navigation to a different resource.

A link with a crappy (or missing) href isn’t a button

I must see things like these at least once a day:

  1. <a class=“btn_addnew”></a> 2. <a href="#"><img src=“path/to/image.gif” /></a> 3. <a href="#"></a> 4. <a href="#">Some button text</a>

In first case, I often see these with background image sprites that give the control the visual look of a button. In this case this item is neither a button or a link. Because this item lacks an href attribute, it is an “anchor”, not a link. As an anchor it is not keyboard focusable. Furthermore, due to the use of a background image sprite, the item has no text alternative for the image and therefore no ‘name’. For low-vision users in High Contrast Mode, the image will disappear. For voice dictation users, they will be unable to use link or button commands on that control. From an accessibility standpoint, this item may as well not exist at all and the use of A here is no better than SPAN .

The second example is being seen less and less these days, superseded as it were, by some variations of 3 or 4. In each of these cases, these objects are only marginally better than the first example. In the first example, the lack of an href attribute meant that the item can’t get focus via keyboard. In these examples we see the use of ‘href=”#”’. Developers often use the hash mark to have a link that (they think) does nothing. The problem is that they’re wrong in multiple ways.

Per the specification, the ‘#’ is a “Fragment Identifier Separator”. In other words, the “#” is meant to precede a string of text which identifies a fragment on the page – a named anchor or an object’s specific ID. Developers think that by having no identifier it points to nothing, and unfortunately they’re 100% right. In certain browser/ operating system combinations, this may also mean that focus is shifted elsewhere. In some cases, for instance, it has the apparent effect of pointing to the browser window or body element. From there the tab order re-starts from the beginning.

Imagine this scenario: you’ve programmed a pseudo button which navigates through a wizard-like process with multiple steps, each using that <a href=”#”> link. Each time a keyboard user completes one step, they need to start over at the very top of the page, tabbing through to the next step. Lame.

Perhaps the thing that confounds me the most about using links (or spans or divs) as buttons is that there’s no intelligent argument that can be made in favor of this practice. The BUTTON element can be styled just like links, divs, and spans and no matter which of these elements you choose you still need to bind the relevant events to your control. So if it looks like a button and acts like a button, what compelling reason is there to not just use a button?

TL;DR

  1. DIV s and SPAN s are not buttons
  2. If it navigates, it is a link. Use link markup with a valid hypertext reference
  3. If it triggers an action, it is a button. Use a BUTTON element
  4. If you don’t like how a button looks, style it with CSS.
1 Like
17

@Jerami I couldn’t have said it better myself, Thanks! All I was saying is it’s better to use it for it’s purpose, because if not you could use practically anything as a button or (link) but it would take more work to get to a button’s initial state to then further style and is it even beneficial? Sarcasm Consider using this as your links:

This is a link! Right?

Well kind of, but not really.

<p onclick="myFunction()" style="cursor:pointer;color:#e52;" id="button">This is a link! Right?</p>
  <script>
    function myFunction() {
      document.getElementById('button').style.color = "red";
      window.location.href = 'https://giphy.com/gifs/msnbc-politicsnation-gRHpI3WwY6rsmcEQSC';
    };
 </script>
1 Like
18

No idea why you copy pasted from a 5 year old page. Not to mention you talked about div and span which has nothing to do with the discussion.

<a href="#" aria-role="button">Button</a>

Works just fine for accessibility.

(https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques/Using_the_button_role)

19

Ok just use links I tried explaining it doesn’t seem to work.

20

Shrug… I’m the full-time web developer with 100s of sites made. No issues yet.