What Disadvantages Are There to the <Button> Tag

What disadvantages are there to the button tag?

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.

Update:

I found a library out there that looks promising to fix this.

If you use the ie8.js script from this library: http://code.google.com/p/ie7-js/

It might work out just fine. The IE8.js brings IE5-7 up to speed with IE8 with the button tag. It makes the submitted value the real value and only one button gets submitted.

Are there any drawbacks to using button instead of input type= submit if I'm not supporting IE6/7?

The button element represents a button labeled by its contents.

A <button> can contain phrasing content (except for other interactive content such as <input>).

In my experience there's no problem using a <button> instead of an <input type=button>. IE7- will submit the <button>'s contents, which is odd. That's pretty much all you have to worry about, though.

Not to use div for button functionality

<div> has little or no semantic meaning. It's just a generic container.

<a>, <button>, or <input type=button> all make it much more clear what the thing actually is, what it's supposed to do, etc.

This has several advantages:

• Accessibility: Chances of a screen reader or whatever knowing what to do with an <a> is much greater than it managing to figure out that your <div> is actually a way to communicate back to the web server or whatever.

• User interface advantages: If a user is used to tabbing through clickable elements or whatever, their browser is far more likely to do the right thing if you use an element that clearly indicates that it's there for the user to click/press/whatever. If you use <div>, then the browser might not highlight it or do whatever it normally does to tell the person that they can click it.

• You get the clickability for free, rather than having to attach an onclick or whatever. With a <div>, there's probably no way to make it work without JavaScript. With the other elements, there's at least a hope (especially with <a>).

I'm probably leaving out a ton of other things that I just never thought about and maybe the above aren't the best examples, but I suspect you get the idea.

What's good practice for button ? Can it replace a or is it only meant for forms?

A link links to something - at least it should! It is semantically wrong to do the following:

<a href="#" onclick="doSomething(); return false;">Do something</a>

This should be replaced with a button, as it is there for that purpose - it works as a trigger for something the user (programmer) specifies; the purpose of a <button type="button"> element is thus not clear. In contrast, the purpose of a link is very clear - it should point somewhere!

As HTML is a markup language, it does not matter all that much what you do, if you do not think SEO. You can achieve the same thing with a <a>tag as you can with a <button> tag, like a <span> can act exactly as a <div> - semantically though, it is incorrect.

Are there any disadvantages when using .on ?

.on can also work with dynamically added dom objects

In older versions of Jquery we were using .live, .bind or .click etc but now preferred is .on

read the detail here

http://api.jquery.com/on/

Difference between .on('click') vs .click()

button vs. input type= button / . Which to use?

• Here's a page describing the differences (basically you can put html into a <button></button>)
• And another page describing why people avoid <button></button> (Hint: IE6)

Another IE problem when using <button />:

And while we're talking about IE, it's
got a couple of bugs related to the
width of buttons. It'll mysteriously
add extra padding when you're trying
to add styles, meaning you have to add
a tiny hack to get things under
control.

What are the disadvantages/problems of including scripts in the body of page rather than in the head element?

Read this:

http://groups.google.com/group/closure-library-discuss/browse_thread/thread/1beecbb5d6afcb41?hl=en&pli=1

The short story is that we don't want
to wait for DOMContentReady (or worse
the load event) since it leads to bad
user experience. The UI is not
responsive until all the DOM has been
loaded from the network. So the
preferred way is to use inline scripts
as soon as possible.

<div id="my-widget"></div>  
<script>  
    initWidget(document.getElementById('my-widget'));  
</script>  

Yes, it not as easy to
maintain but it leads to a better user
experience. By intentionally leaving
out DOMContentReady wrappers we have
been able to prevent Google Apps to
use on this anti pattern.

And this:

Using DOMContentReady considered anti-pattern by Google

How can I use the button tag with ASP.NET?

This is an old question, but for those of us unlucky enough still having to maintain ASP.NET Web Forms applications, I went through this myself while trying to include Bootstrap glyphs inside of built-in button controls.

As per Bootstrap documentation, the desired markup is as follows:

<button class="btn btn-default">
    <span class="glyphicon glyphicon-search" aria-hidden="true"></span>
    Search
</button>

I needed this markup to be rendered by a server control, so I set out to find options.

Button

This would be the first logical step, but —as this question explains— Button renders an <input> element instead of <button>, so adding inner HTML is not possible.

LinkButton (credit to Tsvetomir Tsonev's answer)

Source

<asp:LinkButton runat="server" ID="uxSearch" CssClass="btn btn-default">
    <span class="glyphicon glyphicon-search" aria-hidden="true"></span>
    Search
</asp:LinkButton>

Output

<a id="uxSearch" class="btn btn-default" href="javascript:__doPostBack('uxSearch','')">
    <span class="glyphicon glyphicon-search" aria-hidden="true"></span>
    Search
</a>

Pros

• Looks OK
• Command event; CommandName and CommandArgument properties

Cons

• Renders <a> instead of <button>
• Renders and relies on obtrusive JavaScript

HtmlButton (credit to Philippe's answer)

Source

<button runat="server" id="uxSearch" class="btn btn-default">
    <span class="glyphicon glyphicon-search" aria-hidden="true"></span>
    Search
</button>

Result

<button onclick="__doPostBack('uxSearch','')" id="uxSearch" class="btn btn-default">
    <span class="glyphicon glyphicon-search" aria-hidden="true"></span>
    Search
</button>

Pros

• Looks OK
• Renders proper <button> element

Cons

• No Command event; no CommandName or CommandArgument properties
• Renders and relies on obtrusive JavaScript to handle its ServerClick event

---

At this point it is clear that none of the built-in controls seem suitable, so the next logical step is try and modify them to achieve the desired functionality.

Custom control (credit to Dan Herbert's answer)

NOTE: This is based on Dan's code, so all credit goes to him.

using System.Web.UI;
using System.Web.UI.WebControls;

namespace ModernControls
{
    [ParseChildren]
    public class ModernButton : Button
    {
        public new string Text
        {
            get { return (string)ViewState["NewText"] ?? ""; }
            set { ViewState["NewText"] = value; }
        }

        public string Value
        {
            get { return base.Text; }
            set { base.Text = value; }
        }

        protected override HtmlTextWriterTag TagKey
        {
            get { return HtmlTextWriterTag.Button; }
        }

        protected override void AddParsedSubObject(object obj)
        {
            var literal = obj as LiteralControl;
            if (literal == null) return;
            Text = literal.Text;
        }

        protected override void RenderContents(HtmlTextWriter writer)
        {
            writer.Write(Text);
        }
    }
}

I have stripped the class down to the bare minimum, and refactored it to achieve the same functionality with as little code as possible. I also added a couple of improvements. Namely:

• Remove PersistChildren attribute (seems unnecessary)
• Remove TagName override (seems unnecessary)
• Remove HTML decoding from Text (base class already handles this)
• Leave OnPreRender intact; override AddParsedSubObject instead (simpler)
• Simplify RenderContents override
• Add a Value property (see below)
• Add a namespace (to include a sample of @ Register directive)
• Add necessary using directives

The Value property simply accesses the old Text property. This is because the native Button control renders a value attribute anyway (with Text as its value). Since value is a valid attribute of the <button> element, I decided to include a property for it.

Source

<%@ Register TagPrefix="mc" Namespace="ModernControls" %>

<mc:ModernButton runat="server" ID="uxSearch" Value="Foo" CssClass="btn btn-default" >
    <span class="glyphicon glyphicon-search" aria-hidden="true"></span>
    Search
</mc:ModernButton>

Output

<button type="submit" name="uxSearch" value="Foo" id="uxSearch" class="btn btn-default">
    <span class="glyphicon glyphicon-search" aria-hidden="true"></span>
    Search
</button>

Pros

• Looks OK
• Renders a proper <button> element
• Command event; CommandName and CommandArgument properties
• Does not render or rely on obtrusive JavaScript

Cons

• None (other than not being a built-in control)

---

Related Topics