Digital Web Magazine

The web professional's online magazine of choice.

Push my <code>button</code> : Comments

By Aaron Gustafson

September 25, 2006


Dmitry Baranovskiy

September 25, 2006 10:48 PM

You didn


September 25, 2006 10:54 PM

Excellent article!
I was one of the many who dislike the button element, but mostly because of lack of knowledge. This article was so eyes-opener! Good stuff.

@Dmitry, I’m sure IE problems can be fixed, right?

Jeriko One

September 25, 2006 10:56 PM

My guess for the lack of usage is the totally fucked up behavior of Internet Explorer on submit buttons:

- Instead of sending a value, it delivers the content of the submit button. So, a <button type=“submit” name=“button1” value=“getIt”>Let’s do this!<button> will supply “Let’s do this!” instead of “getIt” – And even more worse, if you have multiple submit buttons, all of them will be submitted, no matter which one you pressed – no distinction possible

And no, this problem can’t be fixed

Cory Hudson

September 25, 2006 11:02 PM

Yes, the Internet Explorer problem is a terrible one. A year ago I went button-crazy and recommended using it in 2 projects at work. My boss loved the level of CSS control and so did I. Then our clients kept telling us our PHP applications weren’t working in IE, and after a lot of debugging I figured out that the button values don’t get passed by IE the same. (Shame on me for only testing the design cross-browser and not the form functionality as well). Anyway, a quick change of everything to <input type=“submit”> did the trick.

Button tags still have their uses for simple forms with only one submit choice, but it’s back to <input type=“image”> for me.


September 26, 2006 4:09 AM

Simplemente “genial”... tan extenso como f

Marcos Neves

September 26, 2006 4:44 AM

A worst problem is that google can

Ilija Studen

September 26, 2006 5:05 AM

I’ve been using buttons for a long time, without any problems (I


September 26, 2006 5:22 AM

Echo other comments above: I still don’t understand how people can advocate designs that don’t work in IE. It may be a bear, but it’s unavoidable. Most of us don’t have the luxury to say “best viewed in XXX browser”. :( Like others, I’d advocated the use of “button” in a project at work, only to have it ripped out at the 11th hour when we ‘discovered’ these layout issues.

Michael Thompson

September 26, 2006 6:07 AM

Think of it as a revolution: the day we as designers start sending a non-sympathetic “fuck you” to IE is the day the web loses its training wheels. If the whole of the internet was comprised entirely of non-IE sites—want to guess what would happen to the share and usage of that horrible browser?

Designing sites for IE should be an afterthought. Remember that as developers, we control what goes out onto the web. If we organized, we could force IE users off the web until IE fully adopted standards (don’t get me started on IE7, either), or until everyone adopted a different browser.

Removing the monolithic IE from the browser market would allow for faster evolution and adoption of standards, accessibility, and web technologies. Imagine designing something in Illustrator and exporting that to SVG to be used as a scalable vector graphic in a page with a fluid layout. Full resolution independence with scalable graphics!

I don’t care if you’re pro-life, it’s time to abort IE for good.

Pete Fairhurst

September 26, 2006 8:24 AM

The day we as designers start sending a non-sympathetic “fuck you” to IE is the day the web loses its training wheels.

If you’d said “[...] is the day the wheels fall off the Internet”, I might have been inclined to agree with you. This sort of elitist, self-serving attitude does no-one any favours, except those who constantly whine that they can’t play with all the of toys all of the time. Grow up.

As a web developer you should be well aware of your responsibilities to serve as much of your content to as much of the web as possible. If you know what’s right, you’ll do what the majority ask of you; that is, to give them what they want by whichever means they’ve used to access it.

What next? Deliberately exclude everyone who doesn’t use your preferred browser? It’s 2006, not 1996 – “Netscape Navigator 4.0+ and a resolution of 800×600 or better (in millions of colours) is not required.”

As to the examples given in the article, I’m delighted to see XHTML 1.0 Strict validation being passed on all of them. It’s always nice if you can get that extra little rubber stamp onto something fresh and exciting. I’ll be sure to use this technique where ever I can in future.

Great article, thanks for sharing.


September 26, 2006 8:49 AM

Greatly appreciate your well thought out insights on some common

Will Rickards

September 26, 2006 9:42 AM

If you can guarantee javascript support in the user base then buttons work great with an additional hidden input to be able to track which button was pressed. If you don’t have that luxury then as has been said only simple forms with one submit can effectively use button elements.

Submitting the contents of the button instead of the value is a serious problem. If you are using a method=get form, the URL becomes a horrid mess. If you are parsing the data on the server side and have say 5 buttons, what a lot of extra crap to parse through. Hopefully they fixed this in IE7.

I recently used them quite extensively in a project and it worked well. But I’m basically guaranteed every user is using IE 6 with javascript enabled. I didn’t notice any layout issues. But I usually reset the margin and padding of all form elements to 0 by habit and then increase as necessary. Anybody have more specfics on the layout issues?

Harmen Janssen

September 26, 2006 10:23 AM

Thanks for some great examples!
I’ve enjoyed seeing creative use of this element, but I must say, I’ve never seen such non-semantic markup for pagination links. In my opinion, that has nothing to do with a form whatsoever.

Chris Botman

September 26, 2006 5:50 PM

Similar to the Google problem, when you use buttons instead of links for pagination I can no longer open the target URL in a new window or tab.

Buttons for pretty form submission = good.
Buttons for the sake of it when you should be using a link = bad.


September 26, 2006 11:49 PM

Very nice read; definitely an eye-opener in sense of using alternatives to tags we know and use all the time. In all the form making tutorials I’ve eve encountered, I’ve never heard mention of the button element; it’s always about the input type=“button”

However, if the article had perhaps flew over a short comparison of the two types of form elements it would be even better. Something like why you should use the button and why you should use the input type=“button”

Nice examples too!


September 27, 2006 1:23 AM

Interesting article. I didn’t know about the button tag and I’m looking forward to playing with it. However, I think the last example is pretty bad from a semantics point of view – pagination links are… links, and should be treated that way (and what’s with the extra span tags?).

Michael Thompson

September 27, 2006 5:24 AM


Hey, did you even read what I wrote? “The day we…” means that it’s not happening now, idiot. I realize I have to cater to many audiences and I do just that daily — but I’d love to see IE drop from the market and have other browsers pick up the slack. More secure browsers with better standards implementations and accessibility features? You’d be crazy to not want that.

Which is where you are. It’s not elitist to demand better from software vendors and it’s certainly not elitist to suggest that perhaps one of these vendors should just go away (from Web offerings, at least).

So what exactly is your point? I want a better browsing experience for everyone. When designers cater to IE they use hacks, javascript, tables, and other trickery to make the page render properly. These tricks make the results of screen readers and content parsers completely worthless. Imagine being blind and hitting a page with no semantic markup and packed with tables.

I’ll say a web-prayer for you and your ignorant soul, Pete. Maybe someday people like you will see past the “toy” aspect, and accept that these new technologies are going to enable entire groups of people to use the web in ways they’ve only dreamed.

To summarize: web technologies are not toys, and I’d argue it’s you who needs to grow up.

Aaron Gustafson

September 27, 2006 8:19 AM

I think it may be helpful to keep in mind that this article focuses on standards-based development following the W3C spec for the button element and does not delve into the ways in which some browsers (ahem) incorrectly interpret/implement them. This article is not a treatise on the button element, it’s simply a reintroduction to its practical use in web forms.

As for the final example, while I would agree that most pagination implementations would best be served using a simple ol with as, there are some instances (in multipage forms, for instance) when this technique would be very useful. And to answer Maaike’s question about the empty span elements: it is an application of remote rollovers. They needn’t just for links, after all.


September 27, 2006 12:58 PM

I think you may have mixed up the labels between Opera and Safari in your graphic. I don’t know about Opera, but Safari’s buttons certainly don’t look like the first example…


September 28, 2006 2:45 AM

The button-element is not being supported by XHTML MP. So it is unlikely that you can use your application with a mobile phone when you use button instead of input.


September 29, 2006 1:49 PM

I like this article, but I have a comment about this:
“Some may argue for the use of native form controls because they


October 5, 2006 4:12 AM

Great article, Just wanted to know how to have a link that can be clicked in a button text something like W3S


Anthony Navarre

October 5, 2006 8:40 AM

@Pete & Michael,

You’re both right. We need to cater to IE if we want to survive, but if we ever want to make our services as web devs more affordable/agile/accessible/etc, we will eventually have to drop browsers that are completely uncompliant with standards.

Don’t bicker, guys…I think we’re all on the same side here.

In the meantime, I appreciated the article, but I’m having to jump thru many hoops to get the tag to work the way I need it to for my project. Supporting IE (in this button tag scenerio, as well as others), it seems, isn’t turning out to be good for me, my client, or the site’s users.

While I’m on the subject, anyone know if there’s a javascript state like “clicked” or “active” or “checked” when serializing a form?

Anthony Navarre

October 6, 2006 7:08 PM

Just realized I wasn’t specific enough in my final inquiry…I want to get the “state” of a button tag when a form is submitted and serialized. I’m using prototype to fire a serializer onsubmit and I’m hoping to add something to prototype’s serializer, ie:

button: function(element) { if (element.[what goes here?]) return [, element.value]; },


October 8, 2006 4:17 AM

Very good read, Aaron. I was actually thinking of a more flexible way to style my form control elements, and was having some trouble with styling inputs for IE. Will definitely try it with buttons now. Bookmarked!

Phil M

October 9, 2006 3:37 AM

Remember that as developers, we control what goes out onto the web. If we organized, we could force IE users off the web until IE fully adopted standards (don’t get me started on IE7, either), or until everyone adopted a different browser.

I’ll forward your post on to my sales team when we lose 85% of our leads because I’ve switched to multiple button tags in my site’s forms, rather than inputs.

Anthony Navarre

October 9, 2006 4:25 PM

An interesting development in my current work:

I’m using Rails and some AJAX voodoo to build for admin areas only, so obviously javascript is a must, but not such a big deal since I’m not limiting any usability for the site’s visitors.

Rails by default uses the prototype library for AJAX calls so what I did was add a title attribute to match the desired value attribute, thus avoiding any necessity to change the innerHTML of the button… better to see the code than explain:

Thanks in part to some posts at
In prototype.js:

—Form.serialize: function(form) {
++Form.serialize: function(form,ev) { var elements = Form.getElements($(form)); var queryComponents = new Array();
++ if (!ev) { ev = window.event; }
++ if (ev!=‘undefined’) {
++ if(ev.explicitOriginalTarget) { elements.unshift(ev.explicitOriginalTarget); }
++ else if(ev.srcElement) { elements.unshift(ev.srcElement); }
++ }

for (var i = 0; i

and also in prototype.js, add a “button” definition for Form.Element.Serializers:

button: function(element) { return [, element.value]; },

and in Rails, redefine ActionView::Helpers::PrototypeHelper.form_remote_tag as follows:

def form_remote_tag(options = {}) — options[:form] = true ++ options[:with] = “Form.serialize(this,event)” options[:html] ||= {} options[:html][:onsubmit] = “#{remote_function(options)}; return false;” options[:html][:action] = options[:html][:action] || url_for(options[:url]) options[:html][:method] = options[:html][:method] || “post” tag(“form”, options[:html], true) end

Untested for IE, but no reason I can tell that it shouldn’t work. Only caveat I have so far is that I can’t support this technique for Safari since Safari says that the form itself it the srcElement, and not the button that has been pressed.

Anthony Navarre

October 9, 2006 4:39 PM

OOPS! That should be:

button: function(element) {
return [, element.title];

I use element.title here, instead of element.value because that way I get around the IE problem and it’s easier to add a title attribute than to try to assign some kind of onclick magic everytime I need to use a button. Especially since my database-driven app might potentially produce more than 100 individual buttons for a given page.

I chose title instead of id or class because I often might need to use those for more important needs, especially given that I am using AJAX. Use whatever works for your app, I guess.

David Levin

October 19, 2006 11:21 AM

Nice article. I would have liked to see more information on the way IE 6 handles the ‘button’ tag. Since most people use IE, I think it would be an important enough topic to put in the main article.

Hopefully the evolution of IE 6 into IE 7 will resolve these issues.

Martijn v.d. Ven

October 20, 2006 7:07 AM

So, why does Digital-Web uses input to display the send and preview buttons below the comments?

Exelent article.
Maybe it does have some problems on IE, but it seems people are working on “hacking” IE problems every minute anyway.
Never really used the button-tag, I better start with them.

Fr. Greetings,

Sorry, comments are closed.

Media Temple

via Ad Packs