bug 341 - the button element submits the wrong value in IE

Issue: #341
Affects: IE5, IE5.5, IE6, IE7
Fixed in: IE8 Beta 1

The button element in HTML, just like an input element (of type button) is designed (by spec) to submit the contents of the value attribute when it is pressed to submit a form. However in Internet Explorer, this functionality is broken as it submits the innerHTML of the button element rather than the contents of the value attribute.

Example:

<button value="true_content" name="doAction">
  <span style="font-weight:bold;">Please</span> click <em>Me</em>!
</button>

If a user clicked this button, the server should get a parameter called "doAction" with a value of "true_content". IE on the other hand, will return the same parameter, with the value ' <span style="font-weight:bold;">Please</span> click <em>Me</em>!'.

Known Workarounds: None. See MSDN for the latest news on when the button element will be fixed.

Related Issues: bug 101.

bug 101 - buttons render stretched and distorted in IE (WinXP)

Issue: #101
Affects: IE6, IE7 (on WinXP)
Fixed in: IE8 Beta 1

On Windows XP in IE6 or IE7, with the default themes applied the input button element renders stretched and distorted when the length of the value exceeds 17 characters.

In fact, the padding on the button also changes, depending on the length of the value attribute, which is also a buggy.

Example:

<input type="button" name="test" value="Distorted in IE on XP" onclick="alert('How do I look?');"/>

View this page in Windows XP in IE6 or IE7 to see the rendering bugs.










You don't even have to use Windows XP to see the padding expansion bug. IE6 on Windows2000 or Windows2003 will also display the issue.

Known Workarounds: CSS Hacks.

Example Workaround Code:

{soon}

Related Issues: None.

A day in the life of a Web Application Developer

Once Upon A Time:
Every Web based application has to start somewhere, but I'm going to jump in to a very specific spot.

Every Web based application has forms, likely lots of forms, and each of those forms has buttons, often at least a few.

Buttons are the perfect UI component. Just looking at them it is obvious what to do with them , and design wise they provide the perfect constraints to apply actions to a form.

Buttons usually have words that depict exactly what they are for , they display a pointer cursor when you mouseover them, and they can even be displayed in a disabled state , indicating that a particular action is not available at this time.

As a developer, you have the choice to "roll-your-own" fancy buttons by using images and/or css, but the basic input type="button", does all the work for you.

...

So if they are so perfect, why devote an article to them? ...well, they are great, but there are drawbacks as well.

So its day 2 or 25 or 457 of your web application's life. You've built a pile of forms and pages to interact with your software, and everything is great. In fact, if you take a minute to ponder, those buttons you have, certainly add up... well into the hundreds now, and you add more with every update to the application.

You used the element designed for this task, the <input type="button".../>. Straight "out-of-the-box" they had everything you needed. You could submit forms, execute JavaScript, enable, disable, even change the text on the button, or the value it submitted.

Then one day, things took a bit of a nose dive. Users started to complain that the buttons looked ugly, if they were wordy, distorting as if melting at the sides. Welcome to the world of bugs. This bug, is the famous Windows XP Button bug (bug 101), which under most circumstances, causes buttons with 18 or more characters to start stretching oddly. There are some minor tweaks you can make, to try and fix a bit of the stretching, but they aren't perfect, and they will still eventually fail.

So, depressed and frustrated, you check your specs at the W3C and realize all is not lost, there is a <button>Click Me</button> element that might just save the day!

Shattered Dreams:

After building some super sexy button elements, you figure you have it licked! Not only do these buttons look like buttons, but you can add images, spans of text, line breaks, you name it! Awesome!

Everything is great, until you submit that first form.

Update=<img src="http://www.mydomain.com/img/gear.png" class="icon"/><span class="buttonText">Update Configuration</span>

What on earth is all that garbage HTML when I submit my form? Welcome to (bug 341).

So, using the button element won't solve your problem, and in fact, you can't even use it in your application because one browser "Broke The Web" ^~TM. It's too bad, because beyond the animated GIF bug for buttons (reference), the button element would be the perfect control for great looking Web 2.0 applications.

Like many 12 step programs, you've reached level 1. Admitting defeat. Try as hard as you can to follow the specs and use the proper elements, you have to concede that you may need to do some hacking, or break the rules.

---

You also start getting a lot more emails from users complaining that their auto-completion works fine on other web sites, and applications, but it isn't working on yours? After gathering the info, it turns out that only your IE users are affected.

Strange? Auto-complete is a feature of the browser, and you don't specifically go out of your way to block it anywhere in your application. Turns out, that Auto-complete was implemented in a buggy manner in IE (bug 137) and now your application suffers because of it. At least there is a hackable workaround for this issue.

---

It's the afternoon now, and you're keen to implement a new section in your application. The new section does some neat stuff with AJAX calls to refresh parts of the page with new data, and executes some server-side validation to improve usability. As part of this process, some of the options in some dropdowns need to be disabled.

Everything works fine in Firefox, Safari, and Opera... but before you commit your new code, you test it in IE... What? there's no JavaScript error, but the options do not dynamically get disabled/enabled as needed! You've inadvertently discovered that IE doesn't support disabled options (bug 293) and you struggle to figure out a realistic workaround. Ugh!


The day isn't over yet!... To be continued...