Making default entry in search text box disappear on click

[spence]

Hi All

How do I make it so that when a user clicks in a search text field, the
default entry (in this case "Search") is removed automatically - they
are then faced with a blank search box and can type straight away

Thanks in advance

[kchayka]

Philip Ronan wrote:

But from my experience
most browsers select the contents of text boxes when they receive focus.
I don't know of any browsers that automatically select the entire
contents of a text box unless the user tabbed to the field. A single
mouse click doesn't do it, for sure.
If
not, then the user just has to hold the key down a bit longer until the
auto-repeat kicks in. Or if the user is really pressed for time, perhaps
control+delete might do it, or (gasp) control-A, delete. This isn't really a
big deal.

Not a big deal to you, obviously. For the rest of us, it is an annoyance
to some and just plain confusing to others. In either case, it's rude to
make your visitors work to use your site.

So what's the problem?

The problem seems to be your lack of consideration to your visitors.

--
Reply email address is a bottomless spam bucket.
Please reply to the group so everyone can share.

[Spartanicus]

Philip Ronan <in*****@invali d.invalid> wrote:

A user behaviour study [1] that I helped to set up and conduct clearly
showed that most users are lost when there is no submit button. Even
amongst computer literate under 35's the percentage was quite high.
Fair enough. But if we're talking about a search box that appears on every
page of a website I'm sure people will soon figure out what it's for.

This wasn't an issue, all cases were appropriately labeled.
Did the buttonless search box in your study have any initial content?

The value of place-holding text [1] was tested separately using forms
with submit buttons. It helped somewhat to convey the function of the
various fields for some user groups (55+ and computer novices mainly).
On the other hand in a significant number of cases the place-holding
text was left in place by those same users. The use of client side
scripting to clear the place-holding text would help to reduce the
latter problem.

[1]
http://www.w3.org/TR/1999/WAI-WEBCON...-place-holders

--
Spartanicus

[Philip Ronan]

"Darin McGrew" wrote:

The example in the HTML 4 spec is not--nor was it intended to be--a good
example of an HTML form.
Is that a fact, or an opinion?
Other forms shown in the HTML 4 spec, which are intended to be good
examples of an HTML form, do include submit buttons.

It is still nevertheless the case that the submit button is *optional* in
forms with a single text field.

--
phil [dot] ronan @ virgin [dot] net
http://vzone.virgin.net/phil.ronan/

[Philip Ronan]

"kchayka" wrote:

I don't know of any browsers that automatically select the entire
contents of a text box unless the user tabbed to the field. A single
mouse click doesn't do it, for sure.
Obviously I don't know what browser you're using. Maybe a double click will
work?
The problem seems to be your lack of consideration to your visitors.

There's more than one way to skin a cat. I'm not claiming this is the *best*
way of doing things. It's just *a* way of doing things. It has drawbacks as
well as benefits. But it works. For everybody.

Obviously I wouldn't use it on a website where Javascript-disabled visitors
would be liable to fly into a confused rage at having one second of their
time wasted.

--
phil [dot] ronan @ virgin [dot] net
http://vzone.virgin.net/phil.ronan/

[Dr John Stockton]

JRS: In article <Pi************ *************** ****@ppepc56.ph .gla.ac.uk

, dated Wed, 6 Jul 2005 13:40:19, seen in news:comp.infos ystems.www.aut

horing.html, Alan J. Flavell <fl*****@ph.gla .ac.uk> posted :

So ... you're saying that web designers should never use Javascript on the
WWW,

No, I'm not saying that. I'm saying that the design should never
*rely* on javascript being successfully executed. Using it to provide
optional extra conveniences is perfectly fine.

That's rather a blinkered attitude.

It applies to web pages that are used to send data to a server, in which
case a properly-designed page will be usable without script.

It does not apply to pages such as <URL:http://www.merlyn.demon.co.uk/as
tron-3.htm>, the purpose of which is to deliver calculators to the user,
calculators which require no post-delivery service from the server, and
which can be used on- or off- line. (( In this case, there is *no*
possibility of doing the calculations at the serving establishment. ))

--
© John Stockton, Surrey, UK. ?@merlyn.demon. co.uk Turnpike v4.00 IE 4 ©
<URL:http://www.jibbering.c om/faq/> JL/RC: FAQ of news:comp.lang. javascript
<URL:http://www.merlyn.demo n.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demo n.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.

[Alan J. Flavell]

On Thu, 7 Jul 2005, Dr John Stockton wrote:

No, I'm not saying that. I'm saying that the design should never
*rely* on javascript being successfully executed. Using it to provide
optional extra conveniences is perfectly fine.
That's rather a blinkered attitude.

On the contrary, it's not only in accord with the principles of the
WAI, but it offers the optional conveniences to all who have consented
or are willing to consent to executing js, while still offering basic
functionality to everyone else. I can't see why you'd feel you need
to object to that.
It does not apply to pages such as
<URL:http://www.merlyn.demon.co.uk/as tron-3.htm>, the purpose of
which is to deliver calculators to the user, calculators which
require no post-delivery service from the server, and which can be
used on- or off- line. (( In this case, there is *no* possibility of
doing the calculations at the serving establishment. ))

I would have to rate that as an "optional extra convenience", not
essential to the "design of the page" in the terms of my quoted
objection. Although it understandably doesn't actually work, this
page could be successfully viewed without js enabled, if it were not
for this piece of unrelated drivel:

Some of this page needs a compatible Symbol font, in which for example
p is displayed as the Greek letter pi and Ö as Root; otherwise,
letters may be displayed in place of Greeks and Maths signs.

Displaying the letters is *correct*, and has been throughout the life
of HTML, although it wasn't till around 1995 that the issue was first
pointed out, it seems. Displaying anything else is a browser bug,
which is slowly getting repaired, and it is foolish to rely on a
browser bug, and additionally foolish to explicitly ask one's users to
rely on such a bug.

You'd do well to phase this rubbish out without delay, in favour of
standards-conforming character representation. A.Prilop will be along
any moment to pour appropriate scorn...
But to come back to your point:

There's certainly an argument to be made that executing a js that has
been stored locally could be less of a risk than allowing a web page
to execute js directly. Indeed "bookmarkle ts" (aka "favelets") work
on just that principle.

have fun

[Dr John Stockton]

JRS: In article <Pi************ *************** ****@ppepc56.ph .gla.ac.uk

, dated Thu, 7 Jul 2005 20:50:57, seen in news:comp.infos ystems.www.aut horing.html, Alan J. Flavell <fl*****@ph.gla .ac.uk> posted :On Thu, 7 Jul 2005, Dr John Stockton wrote:

>No, I'm not saying that. I'm saying that the design should never
>*rely* on javascript being successfully executed. Using it to provide
>optional extra conveniences is perfectly fine.
That's rather a blinkered attitude.

On the contrary, it's not only in accord with the principles of the
WAI, but it offers the optional conveniences to all who have consented
or are willing to consent to executing js, while still offering basic
functionalit y to everyone else. I can't see why you'd feel you need
to object to that.

Because they are not optional extra conveniences, but are the whole
purpose of the page. With script not enabled, the page is rather like a
calculator without its battery - it may be interesting to look at, one
can see what it does, but one cannot *use* it.

In that page, I offer no functionality to those without javascript; I
just let them realise what they are not getting.

It does not apply to pages such as
<URL:http://www.merlyn.demon.co.uk/as tron-3.htm>, the purpose of
which is to deliver calculators to the user, calculators which
require no post-delivery service from the server, and which can be
used on- or off- line. (( In this case, there is *no* possibility of
doing the calculations at the serving establishment. ))

I would have to rate that as an "optional extra convenience", not
essential to the "design of the page" in the terms of my quoted
objection. Although it understandably doesn't actually work, this
page could be successfully viewed without js enabled, if it were not
for this piece of unrelated drivel:

Some of this page needs a compatible Symbol font, in which for example
p is displayed as the Greek letter pi and Ö as Root; otherwise,
letters may be displayed in place of Greeks and Maths signs.

But the page is not intended to be viewed; that is a mere essential
ancillary. It is intended to be executed.
Displaying the letters is *correct*, and has been throughout the life
of HTML, although it wasn't till around 1995 that the issue was first
pointed out, it seems. Displaying anything else is a browser bug,
which is slowly getting repaired, and it is foolish to rely on a
browser bug, and additionally foolish to explicitly ask one's users to
rely on such a bug.

You'd do well to phase this rubbish out without delay, in favour of
standards-conforming character representation. A.Prilop will be along
any moment to pour appropriate scorn...
He should have more sense, and remember that the matter has already been
discussed. I prefer to use characters that I can read as desired, and
that most readers see as I desire, to ones that I cannot see as I wish.
It's quite important to readers that authors can follow their own work.

I should instead have referenced <URL:http://www.merlyn.demon.co.uk/js-
clndr.htm#Ctrls >, which shows only US-keyboard characters. Or
..../holidays.htm which now *requires* script to be of much use, since
I'm unwilling to update the old non-script version each year. BTW, you
might like to check the Scotland holidays.
But to come back to your point:

There's certainly an argument to be made that executing a js that has
been stored locally could be less of a risk than allowing a web page
to execute js directly.

That, whilst no doubt a valid argument, was *not* my point, which was
that local execution can be more convenient for those without permanent
connection to the Net.

--
© John Stockton, Surrey, UK. ?@merlyn.demon. co.uk Turnpike v4.00 IE 4 ©
<URL:http://www.jibbering.c om/faq/> JL/RC: FAQ of news:comp.lang. javascript
<URL:http://www.merlyn.demo n.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demo n.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.