What disadvantages are there to the <button> tag? (It seems there are quite a few problems with ie)

Question

I started using a diagnostic css stylesheet, e.g. http://snipplr.com/view/6770/css-diagnostics--highlight-deprecated-html-with-css--more/

One of the suggested rules highlights input tags with the type submit, with the recommendation to use <button> as a more semantic solution. This is a new tag to me, do you guys recommend it, or are there disadvantages (such as with browser compatibility) that you have run across?

Edit:

Just to be clear, I understand the spec of <button>, it has a defined start and end, it can contain various elements, whereas input is a singlet and can't contain stuff. What I want to know essentially is whether it's broken or not. So despite never having used it before, I'd love to start using it, I just don't know how well it works in the real world. The first answer below does seem to imply that it is broken for uses except outside of forms, unfortunately.

Edit:

Conclusion

Button tag: not worth the trouble, just use input for now.

Button is essentially not worth it while ie6 and ie7 remain in circulation, it seems to be much much more trouble than the minor benefit that it might have been worth.

Answer 1

Everything you need to know: W3Schools <button> Tag

The tag is supported in all major browsers.

Important: If you use the button element in an HTML form, different browsers will submit different values. Internet Explorer will submit the text between the <button> and </button> tags, while other browsers will submit the content of the value attribute. Use the input element to create buttons in an HTML form.

Answer 2

Here's a site that explains the differences: http://www.javascriptkit.com/howto/button.shtml

Basically, the input tag allows just text (although you can use a background image) while the button allows you to add images, tables, divs and whatever else. Also, it doesn't require it to be nested within a form tag.

Answer 3

see the button description in the HTML 4.01 spec

Answer 4

Looks like the main reason to use <button> is to allow for CSS markup of that button and the ability to style the button with images: (see here: http://www.javascriptkit.com/howto/button.shtml)

However, I think the more adopted approach I've seen in (X)HTML + CSS is to use a div and style it completely with images and :hover pseudo-classes (simulating button downpress... can't add more than one link per answer, so just google "div button" you'll see lots of examples of this), and using javascript to do form submission or AJAX call... this also makes even more sense if you don't use HTML forms, and do all submissions with AJAX.

Answer 5

I have this vague memory that an Input needs to be in a form in order to work in IE, button doesn't.
Button can have children, input cannot.
Not verified, just thought the direction tip might help.

Answer 6

Is it broken or not:

As usual, the answer is "it works fine in all major browsers, but has the following quirks in IE." I don't think it will be a problem for you though.

The <button> tag is supported by all the major browsers. The only support problem lies in what Internet Explorer will submit upon pressing a button.

The major browsers will submit the content of the value attribute. Internet exploter will submit the text between the and tags, which also submitting the value of each in the form, instead just the one you clicked.

For your purposes, just cleaning up old HTML, this shouldn't be a problem.

Sources:

1. http://www.peterbe.com/plog/button-tag-in-IE
2. http://www.w3schools.com/tags/default.asp

Answer 7

When using <button> always specify the type, since browsers default to different types.

This will work consistently across all browser:

• <button type="submit">...</button>
• <button type="button">...</button>

This way you gain all of <button>'s goodness, no downsides.

Answer 8

An important quirk to be aware of: In a form that contains a <button/> element, IE6 and IE7 will not submit the form when the <button/> element is clicked. Other browsers, on the other hand, will submit the form.

In contrast, no browsers will submit the form when <input type="button"/> or <button type="button"/> elements are clicked. And naturally, all browsers will submit the form when <input type="submit"/> or <button type="submit"/> elements are clicked.

As @orip's answer says, to get consistent submit behavior across browsers, always use <button type="button" /> or <button type="submit" /> inside a <form/> element. Never leave out the type attribute.

Answer 9

Answering from an ASP.NET perspective.

I was excited when I found this question and some code for a ModernButton control, which, in the end, is a <button> control.

So I started adding all sorts of these buttons, decorated with <img /> tags inside of them to make them stand out. And it all worked great... in Firefox, and Chrome.

Then I tried IE6 and got the "a potentially dangerous Request.Form value was detected", because IE6 submits the html inside of the button, which, in my case, has html tags in it. I don't want to disable the validateRequest flag, because I like this added bit of data validation.

So then I wrote some javascript to disable that button before the submit occurred. Worked great in a test page, with one button, but when I tried it out on a real page, that had other <button> tags, it blew up again. Because IE6 submits ALL of the buttons' html. So now I have all sorts of code to disable buttons before submit.

Same problems with IE7. IE8 thankfully has this fixed.

Yikes. I'd recommend not going down this road IF you are using ASP.NET

Answer 10

Pros:

• The display label does not have to be the same as the submitted value. Great for i18n and "Delete this row"
• You can include markup such as <em> and <img>

Cons:

• Some versions of MSIE default to type="button" instead of type="submit" so you have to be explicit
• Some versions of MSIE will treat all <button>s as successful so you can't tell which one was clicked in a multi-submit button form
• Some versions of MSIE will submit the display text instead of the real value