Archive for the ‘ieFixButtons’ Category

IE8 vs. Buttons

Monday, March 24th, 2008

Remember the ridiculous implementation of the <button> element in IE6 and IE7? Well, I finally had my first hands-on experience with Internet Explorer 8 (beta 1 for developers), so I was able to check if they fixed it. I tried the new IE on a test page I made for the ieFixButtons jQuery plugin. And you know what? It seems the development team really got it right at last! In IE8 buttons do work as nature intended.

But, I also discovered that my website, the one you’re looking at right now, is slightly broken in the new IE. Specifically, the top navigation menu items are not displayed correctly. So far, I haven’t figured out how to fix it, and I wonder if it’s my fault, or if the beta version of IE8 is, well, too beta, and I should wait for the final version to come out. I will lazily assume the latter for the moment.

Buttons Back in Business

Monday, January 14th, 2008

Some time ago, Kevin Hale of Particletree described his rediscovery of the button element. I also made the same rediscovery once, and I had a brief moment of excitement when I realized how useful the button element can be for quickly putting together a nice web-based user interface.

Then came Internet Explorer and my dreams were crushed. The way buttons work in IE (including IE7) is a) standard-incompliant, b) insane, and c) useless. Here’s why:

What the standard says What IE is doing
If the button type is not specified, it defaults to submit. The default type is button.
When a button is used to submit a form, the contents of its value attribute is sent to the server. The inner text of the button is sent to the server.
If there is more than one submit button, only the value of the activated one is sent to the server. The inner text of all buttons is sent to the server.[1]
[1]

This was kind of fixed in IE7 — the other submit buttons are no longer sent to the server. However, it’s still the inner text that is transmitted, not the value.

From a practical point of view, this means that the value attribute is of no use, because it’s not being sent to the server when the form is submitted — instead, you’ll get whatever was placed between the <button> and </button> tags, including any HTML markup (this is just sick!). And, if you have multiple submit buttons in a form, you won’t be able to tell which one was clicked by the user, as they will be all sent to the server. Seriously, IE developers, what were you thinking?

Back then, I was left with two choices: either to forget buttons and keep using plain old inputs, or to fight the evil. And fight I did. Long story short, I wrote a piece of JavaScript (you know, the popular real-time browser bug-fixing technology) code which works around the irrational behavior of buttons in IE.

I’ve recently released the script as a jQuery plugin named ieFixButtons. Grab it if you want to use buttons the way they were supposed to.