A text form field with the word "Google," or whatever value of your choice, set as the default.
An onClick event attached that that form field such that when the user clicks in it, the default value is erased. Probably should deactivate the onclick at this point as well, or future clicks on the control will erase whatever has been typed in by the user.
Probably should deactivate the onclick at this point as well, or future clicks on the control will erase whatever has been typed in by the user.
Either that or restore it only if the current value is different than the default. Also, if you go the manual route you would probably want to toggle the text style/color as well.
Message was edited by: -==cfSearching==- Well, now that I am actually searching with my eyes open, I see a ton of results.
The following is a basic example of creating a browser-like search box with jQuery. You can copy and paste this code into an HTML file and run it from any web browser (it gets the jQuery library from Google's Content Distribution Network for Ajax libraries):
I did test it on Firefox 3.5 and Safari 4 but was too lazy to start my VM to test it in IE. Though, jQuery typically works equally great with IE7 and 8, and is pretty good with 6, too.
Thanks for the recommend of jQuery. I've used Prototype most-often (probably because it was the first such library that I seriously used).
Nevertheless, I have this one reservation about it ... I don't want to give up any part of what <cfform> and <cfinput> gratuitously provides me. ("I'm a lazy s.o.b.," and of course, laziness is a virtue among programmers.)
For example, I know that the <cfinput> tag can hook into the OnBlur event, and maybe other events, and I don't want to do something that interferes with what CF is doing for me. (Also, I don't want to have to peer too closely into the "guts and mechanics" of what CF is doing for me.) Otherwise, I feel that I might be introducing complexity and the potential of error for what is ... basically ... a "special effect." There is no return-on-investment if I make the app in any way error-prone just to do something that is "cute," when a "less-cute" application would have had the reliability that we already know we can count-on from Cold Fusion when left to its own devices.
Now, if you're telling me that I can safely "have my cake and eat it, too" ... within the context of a ColdFusion form and a ColdFusion input-box ... then I want to know more about that. But over-arching all of this is the primary concern that "I do not want this stuff failing in the field." If someone telephones me and says, "that's cute, but what's this error-message and why can't I use your application?" then I'm not where I want to be. I can easily give-up a "special effect" even if it's nice-to-have and asked-for.
That's my thoughts now. Your responses? Can my fears be assuaged?
I guess much of what your asking depends on how you use cfinput for this particular field. If you are adding some auto-magic CF stuff to that field via the cfinput tag, then I would stay away from the jQuery. If you're not using the onblur or onfocus event handlers from the cf tag, then it should not be an issue. Of course, if you're using the onblur or onfocus attribute of cfinput to execute a custom JS function, you could still use jQuery (or Prototype, etc.) in those custom JS functions to easily accomplish the effect.
Long story short, as long as you're not using any auto-magic stuff of cfinput, you should be good to go!!
Apparently the "official" word for this technique is overlabel.
An article published in December of 2006 entitled A List Apart: Making Compact Forms More Accessible (by Mike Brittain) discusses this technique, and in 2008 Brandon Aaron created a JQuery plugin for it.
Which, to my way of thinking, is a ...
Nice link TLC-IT. Thanks for posting it.