Now this, you must see. It is so hilarious I was barely breathing from laughing my a*s off.
But the first one is, in my humble opinion, still the best use of client scripting. With DOM-compliant browsers dominating the fields, developers have enough resources to add client-side validation in the least-intrusive way, without adding any extra markup like
onblur handlers in the HTML itself. All you need is to include one or two external script files.
As long as I can remember, forms have always been problematic. They need to be short but complete, good looking but not confusing, informative but not cluttered.
These requests are often opposite, especially because designer’s view of those aspects is sometimes…hm, different then client’s.
I believe there is only one basic rule: do not change the overall look of the form elements.
People are used to form elements from the operating system they use. Elements like text fields, checkboxes, drop-down lists and buttons are something people deal with in their usual daily apps, and when they see them on the web, they imidiatelly know what to do with them, i.e. how to fill-in/choose data.
The usual victims are text fields and buttons, as they’re easiest to change.
How many of you recognized that this above is input-awaiting field? Hm, ok. What about your dad? It doesn’t matter if he does too. There’s always people that will be confused. And don’t expect them to call customer service - they are embarassed to not know how to fill-up the form and they will simply leave.
It’s nothing to laugh about. What is obvious to one, is stupid to another and unusable to third. Avoid that.
Another reason against the above is that you can’t style drop-down lists similar to that, so the whole form would look unfinished. Change colours or borders, but don’t remove borders or blend the fields into background.
With this in mind, lets see what we can do.
Alex Robinson posted a CSS challenge few days ago on css-discuss list: using 2-level nested list, create a two-line navigation with the following properties:
“current” main item’s sub menu should be always visible
sub menus for other items should display on hover
menu should be liquid, i.e. to be based on ems rather than pixels
Version with floated box fails in IE/Win. In that example, each item is floated to the left, and IE calculates
width:100% for absolutely positioned nested lists from the left edge of the item instead of full viewport width. Yet another IE/Win bug. :(