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...
Posts
