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

[Philip Ronan]

"spence" wrote:

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

<INPUT type="text" value="Search" onfocus="if
(this.value==this.defaultValue) this.value='';">

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

[spence]

Brilliant. Thanks philip.

I tried searching other groups but couldn't find a thing! Perhaps it
was my search criteria? Anyway, it's here now if anyone uses the same
search criteria I was using!

Thanks again

[Jukka K. Korpela]

"spence" <be***********@gmail.com> wrote:

Brilliant.
Really? You got a wrong answer. That's what you usually get by asking
in a wrong group. Dynamic modification of a field's content is not an
HTML matter.
I tried searching other groups but couldn't find a thing! Perhaps it
was my search criteria? Anyway, it's here now if anyone uses the same
search criteria I was using!

Well, maybe I then need to mention that the answer is wrong.

It is wrong because it relies on security holes in browsers (it does
not work if the browser has client-side scripting disabled), for doing
something that need not be done at all. A search box should have
initial content only if the initial content is a _meaningful and useful
default_. It would then be absurd to wipe it out.

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

[Benjamin Niemann]

Jukka K. Korpela wrote:

"spence" <be***********@gmail.com> wrote:

Brilliant.

Really? You got a wrong answer. That's what you usually get by asking
in a wrong group. Dynamic modification of a field's content is not an
HTML matter.

I tried searching other groups but couldn't find a thing! Perhaps it
was my search criteria? Anyway, it's here now if anyone uses the same
search criteria I was using!

Well, maybe I then need to mention that the answer is wrong.

It is wrong because it relies on security holes in browsers (it does
not work if the browser has client-side scripting disabled), for doing
something that need not be done at all. A search box should have
initial content only if the initial content is a _meaningful and useful
default_. It would then be absurd to wipe it out.

If (and only if) there's really a good reason to do something like this, the
'default' (which is probably not a default at all..) should be removed and
*inserted* using scripting, so non-scripted clients just get a blank input.
I've seen too many form submissions like 'Your NameFred Smith' or 'Your
Em*******@example.com' (that was my hard way to learn that this is a bad
idea).
--
Benjamin Niemann
Email: pink at odahoda dot de
WWW: http://www.odahoda.de/

[Philip Ronan]

"Jukka K. Korpela" wrote:

It is wrong because it relies on security holes in browsers (it does
not work if the browser has client-side scripting disabled), for doing
something that need not be done at all.

Get real. This has nothing to do with security holes.

If Javascript is disabled, then the user can delete it with a single
keypress. So what's the problem? Spare us the dogma, please!!

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

[Jukka K. Korpela]

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

"Jukka K. Korpela" wrote:

It is wrong because it relies on security holes in browsers (it
does not work if the browser has client-side scripting disabled),
for doing something that need not be done at all.
Get real. This has nothing to do with security holes.

You never heard of such holes? Not very real.
If Javascript is disabled, then the user can delete it with a
single keypress.
Can he? Are you sure?
So what's the problem?
There was no problem before someone created it by using a default entry
that ain't no default entry but just an annoyance.
Spare us the dogma, please!!

Did you have something to say about HTML authoring for the WWW?

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

[Philip Ronan]

"Jukka K. Korpela" wrote:

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

"Jukka K. Korpela" wrote:

It is wrong because it relies on security holes in browsers (it
does not work if the browser has client-side scripting disabled),
for doing something that need not be done at all.

Get real. This has nothing to do with security holes.

You never heard of such holes? Not very real.

OK please explain what's so insecure about using Javascript to clear the
initial contents of a search box.

If Javascript is disabled, then the user can delete it with a
single keypress.

Can he? Are you sure?

OK, I have to admit I haven't tested this functionality in every single
browser. I've got better things to do, as it happens. But from my experience
most browsers select the contents of text boxes when they receive focus. 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.

So what's the problem?

There was no problem before someone created it by using a default entry
that ain't no default entry but just an annoyance.

An annoyance to you perhaps, but you seem to be the sort of person that gets
annoyed very easily.

Spare us the dogma, please!!

Did you have something to say about HTML authoring for the WWW?

Sure. If you want to add a search box to your web pages but you don't have
much space available, here's something you could try: Create a form with a
single INPUT box containing "Search" as the initial text. That way you can
indicate the purpose of the search box without cluttering your design with
additional LABEL or LEGEND elements. You can even use Javascript to clear
this initial text when the text box receives the focus. Just don't tell
anyone at c.i.w.a.h what you've done.

Will that do?

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

[Alan J. Flavell]

On Wed, 6 Jul 2005, Philip Ronan wrote:

"Jukka K. Korpela" wrote:

You never heard of such holes? Not very real.

OK please explain what's so insecure about using Javascript to clear the
initial contents of a search box.

What's insecure is allowing an untrusted site to execute javascript on
one's browser. The intended purpose is irrelevant for this. If you
don't yet know this, then you aren't in a position to argue about it.

[Philip Ronan]

"Alan J. Flavell" wrote:

On Wed, 6 Jul 2005, Philip Ronan wrote:

"Jukka K. Korpela" wrote:

You never heard of such holes? Not very real.

OK please explain what's so insecure about using Javascript to clear the
initial contents of a search box.

What's insecure is allowing an untrusted site to execute javascript on
one's browser. The intended purpose is irrelevant for this. If you
don't yet know this, then you aren't in a position to argue about it.

So ... you're saying that web designers should never use Javascript on the
WWW, because the visitors to their websites will end up running these
scripts on their browsers.

I'm afraid you lost me there. Can you explain how your argument differs
logically from the statement that newsagents should never sell matches
because people that buy them might set themselves on fire?

Perhaps you're confusing "Javascript" with "Java"?

Surely you know how to disable Javascript in your browser. So if you're
really concerned about this then there's a simple solution. I used to keep
it switched off to prevent pop-up ads from appearing, but that was about as
bad as it got. Now I have a browser that blocks pup-ups automatically.

But to return to the topic of this discussion, the OP's search box is still
going to be perfectly usable with Javascript disabled, so nobody's being
excluded. Most visitors (i.e., the ones that have Javascript enabled) will
see things working as intended. The others will be held up by about 1 second
because they will need to delete the pre-filled text. Is that such a big
deal?

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

[Alan J. Flavell]

On Wed, 6 Jul 2005, Philip Ronan wrote:

What's insecure is allowing an untrusted site to execute javascript on
one's browser. The intended purpose is irrelevant for this. If you
don't yet know this, then you aren't in a position to argue about it.
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.

Keep in mind, additionally, that none of the indexing robots will be
executing your javascript, so anything which *relies* on javascript to
reach a particular resource will not get indexed properly.
Perhaps you're confusing "Javascript" with "Java"?

You're very rude.

[Philip Ronan]

"Alan J. Flavell" wrote:

You're very rude.
I'm sorry you think that way. I'm not *trying* to be rude. I'm just trying
to understand your point of view. I'm still confused.

You joined this thread by remarking that
What's insecure is allowing an untrusted site to execute javascript on
one's browser. The intended purpose is irrelevant for this. If you
don't yet know this, then you aren't in a position to argue about it.
Then you "clarified" your position by stating 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.

Those viewpoints just aren't consistent. If you check back through this
thread, I think you'll find that my suggested solution to the OP's problem
doesn't *rely* on the availability of Javascript, because the initial text
can easily be deleted by other means. It also provides extra convenience for
users by eliminating the need for LABEL and LEGEND elements that might, in
some cases, have an adverse effect on the design of a web page.

So can you please tell me what I'm doing wrong and why I'm not in a position
to comment on this topic?

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

[Jukka K. Korpela]

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

Did you have something to say about HTML authoring for the WWW?
Sure.

Let's see.
If you want to add a search box to your web pages but you
don't have much space available, here's something you could try:
Create a form with a single INPUT box containing "Search" as the
initial text.

What you should _do_ is to make space, by abandoning wrong ideas about
squeezing essential elements into the size of a small stamp. Do, or do
not; there is no try.

Using "Search" as initial text is simply wrong, since it's defined as
_default_ text. It does not solve the space problem. It does not make
it clear that it is a search box; it is _not_ a label, but initial
content.

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

[Philip Ronan]

"Jukka K. Korpela" wrote:

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

If you want to add a search box to your web pages but you
don't have much space available, here's something you could try:
Create a form with a single INPUT box containing "Search" as the
initial text.
What you should _do_ is to make space, by abandoning wrong ideas about
squeezing essential elements into the size of a small stamp. Do, or do
not; there is no try.

I don't recall mentioning postage stamps anywhere. In fact this technique
could actually help to free up space so that things *don't* have to be made
excessively small. What's wrong with that?
Using "Search" as initial text is simply wrong, since it's defined as
_default_ text.
Where exactly is this definition you're referring to? In the HTML 4.01
specification, it says:

value = cdata [p.50] [CA] [p.49]
This attribute specifies the initial value [p.220] of the control.
It is optional except when the type attribute has the value "radio"
or "checkbox".
It mentions an "initial value" there, but I can't see the word "default". In
case you're interested, all it says on page 220 is:
In general, a control's "initial value" may be specified with the
control element's value attribute.

Again, it doesn't say anything about this being the "default" value.
It does not solve the space problem.
How so?
It does not make it clear that it is a search box;
Just how clear do things have to be? I think anyone with a brain would be
able to figure it out. What else do you suppose people might mistake this
search box for?
it is _not_ a label, but initial content.

Yes, that's correct. In fact you might like to call it an inventive usage of
initial content that eliminates the need for a label. I'm guessing you might
not, however :-(

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

[Darin McGrew]

"Jukka K. Korpela" wrote:

it is _not_ a label, but initial content.

Philip Ronan <in*****@invalid.invalid> wrote: Yes, that's correct. In fact you might like to call it an inventive usage of
initial content that eliminates the need for a label. I'm guessing you might
not, however :-(

Rather than using "Search" as the initial content of the text field (and
then having to deal with the problems that creates), why not just use
"Search" as the label on the submit button? It's clear, it's expected, it's
simple, it works for everyone, and it has no unpleasant side effects.
--
Darin McGrew, mc****@stanfordalumni.org, http://www.rahul.net/mcgrew/
Web Design Group, da***@htmlhelp.com, http://www.HTMLHelp.com/

"Cheaters never win; they just finish first." - Johhny Hart

[Jukka K. Korpela]

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

It mentions an "initial value" there, but I can't see the word
"default".

Look for meanings, not words. The "initial value" is the value that is
submitted along with other form data, unless the value is changed.
The common way of expressing this fact is the phrase "default value".

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

[Philip Ronan]

"Jukka K. Korpela" wrote:

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

It mentions an "initial value" there, but I can't see the word
"default".

Look for meanings, not words. The "initial value" is the value that is
submitted along with other form data, unless the value is changed.
The common way of expressing this fact is the phrase "default value".

Meanings. OK then. In your last post you said that using "Search" as initial
text is "... simply wrong because it's defined as default text". So where
*is* this definition? Is it perhaps just a figment of your imagination? If
so, then the meaning of your argument is basically "It's simply wrong
because I say so."

I daresay the word "Search" probably wouldn't be used as a search term very
often. An empty string isn't a particularly useful search term either. But
as I keep saying, in this case the initial text is there to identify the
purpose of the search box, so it's serving a useful purpose.

It's also perfectly useable, valid HTML. So why all the fuss?

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

[Philip Ronan]

"Darin McGrew" wrote:

"Jukka K. Korpela" wrote:

it is _not_ a label, but initial content.

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

Yes, that's correct. In fact you might like to call it an inventive usage of
initial content that eliminates the need for a label. I'm guessing you might
not, however :-(

Rather than using "Search" as the initial content of the text field (and
then having to deal with the problems that creates), why not just use
"Search" as the label on the submit button? It's clear, it's expected, it's
simple, it works for everyone, and it has no unpleasant side effects.

You can do that if you like.

You can also omit the submit button altogether. The form can still be
submitted without it. And without any unpleasant side-effects apart from
getting roasted in this NG.

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

[Alan J. Flavell]

On Wed, 6 Jul 2005, Philip Ronan wrote:

[I'm reinstating the relevant context:]

Perhaps you're confusing "Javascript" with "Java"? "Alan J. Flavell" wrote:

You're very rude.
I'm sorry you think that way. I'm not *trying* to be rude. I'm just trying
to understand your point of view. I'm still confused.

You joined this thread by remarking that

What's insecure is allowing an untrusted site to execute javascript on
one's browser. The intended purpose is irrelevant for this. If you
don't yet know this, then you aren't in a position to argue about it.

Then you "clarified" your position by stating 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.

Those viewpoints just aren't consistent.

The inconsistency is only in your own mind. If you'd been paying
attention to any serious discussion on these principles, you wouldn't
be making such a silly claim.
If you check back through this thread, I think you'll find that my
suggested solution to the OP's problem doesn't *rely* on the
availability of Javascript, because the initial text can easily be
deleted by other means.

Then why are you raising this silly argument, if you already know that
one should not *rely* on javascript being available, and think you can
do it compatibly?

I conclude that your answer to my point was essentially "yes, I agree
with what you say, and if you read the detail of my earlier posting
you'll see that I'm already doing it that way, although I omitted to
say it in so many words".

It remains then only to discuss whether there's any point in
filling-in a default submission value, what that value could usefully
be, and how inconvenient it might or might not be for users to delete
it. But those detailed points are already being discussed by others
and I don't care to get involved in them. It was the more basic
principle that I felt I needed to dispute.

(Benjamin Niemann has calmly posted a solution which is compatible
with the principles which I'm promoting.)

all the best

[Jukka K. Korpela]

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

Meanings. OK then. In your last post you said that using "Search"
as initial text is "... simply wrong because it's defined as
default text". So where *is* this definition?

In the HTML specification, as I explained. Did you already forget to
look for meanings, not words?

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

[Darin McGrew]

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

You can also omit the submit button altogether. The form can still be
submitted without it.

Well, yes. And windows can still be scrolled even when the author removes
the scrollbars.

But it doesn't seem very user-friendly to remove the most obvious and most
familiar mechanisms for submitting a form or scrolling a window.
--
Darin McGrew, mc****@stanfordalumni.org, http://www.rahul.net/mcgrew/
Web Design Group, da***@htmlhelp.com, http://www.HTMLHelp.com/

"Cheaters never win; they just finish first." - Johhny Hart

[Philip Ronan]

"Jukka K. Korpela" wrote:

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

Meanings. OK then. In your last post you said that using "Search"
as initial text is "... simply wrong because it's defined as
default text". So where *is* this definition?

In the HTML specification, as I explained. Did you already forget to
look for meanings, not words?

Then please take your own advice. Your argument has no basis other than a
bogus assertion based on your own biased judgement.

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

[Philip Ronan]

"Alan J. Flavell" wrote:

The inconsistency is only in your own mind. If you'd been paying
attention to any serious discussion on these principles, you wouldn't
be making such a silly claim.
Alan, earlier today you responded to my suggestion about using Javascript to
clear the initial contents of a search box as follows:
What's insecure is allowing an untrusted site to execute javascript on
one's browser. The intended purpose is irrelevant for this. If you
don't yet know this, then you aren't in a position to argue about it.
If you can't see the inconsistency between that statement and your
subsequent assertion that using Javascript to provide "extra conveniences"
is "fine" then frankly there's not much point in me trying to continue a
logical discussion here.
Then why are you raising this silly argument, if you already know that
one should not *rely* on javascript being available, and think you can
do it compatibly?
Please look back through this thread and check who said what. All I did was
propose a solution to the OP's question. Since then I've been dodging
brickbats from you and Jukka. I'm not the one raising silly arguments.
It remains then only to discuss whether there's any point in
filling-in a default submission value, what that value could usefully
be, and how inconvenient it might or might not be for users to delete
it.
In a nutshell, that's what this whole thread has been about.
But those detailed points are already being discussed by others
and I don't care to get involved in them. It was the more basic
principle that I felt I needed to dispute.

I see. So when you made your caustic remark about my suggestion to use
Javascript to clear the initial contents of a search box, you were *in fact*
making a general comment about the "basic principles" of Javascript? Perhaps
a better place for such comments would be in a thread where people are
discussing the basic principles of Javascript, and not its specific use as a
means of clearing the contents of a search box. Just to avoid confusion...

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

[Philip Ronan]

"Darin McGrew" wrote:

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

You can also omit the submit button altogether. The form can still be
submitted without it.

Well, yes. And windows can still be scrolled even when the author removes
the scrollbars.

But it doesn't seem very user-friendly to remove the most obvious and most
familiar mechanisms for submitting a form or scrolling a window.

Don't know about you, but I normally use the return key to submit
single-line forms.

Take a look at <http://www.w3.org/TR/REC-html40/interact/forms.html#h-17.8>.
In the suggested replacement for the (deprecated) ISINDEX element, you'll
see a form with no submit button. There are no accessibility or
user-friendliness issues with this technique that I am aware of.

Incidentally, how do you scroll windows when there are no scroll bars?

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

[Darin McGrew]

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

You can also omit the submit button altogether. The form can still be
submitted without it.

I wrote: Well, yes. And windows can still be scrolled even when the author removes
the scrollbars.

But it doesn't seem very user-friendly to remove the most obvious and most
familiar mechanisms for submitting a form or scrolling a window.

Philip Ronan <in*****@invalid.invalid> wrote: Don't know about you, but I normally use the return key to submit
single-line forms.
So do I. But I wouldn't try to hide the submit button from those who
normally use it.

I normally use shift-click and ctrl-shift-click to open links in new
windows. But I wouldn't try to hide the context menu from those who
normally use it.

I normally use ctrl-P to print web pages. But I wouldn't try to hide the
File > Print... menu from those who normally use it.

And so on.
Take a look at <http://www.w3.org/TR/REC-html40/interact/forms.html#h-17.8>.
In the suggested replacement for the (deprecated) ISINDEX element, you'll
see a form with no submit button. There are no accessibility or
user-friendliness issues with this technique that I am aware of.
The purpose of that example is to demonstrate a form that replicates the
deprecated ISINDEX element. If you add a submit button, then you've added
something beyond what ISINDEX provides, and the example is less clear.

Are there any other W3C example forms that omit the submit button?
Incidentally, how do you scroll windows when there are no scroll bars?

I generally use the keyboard (page up, page down, home, end, and arrows,
possibly modified by ctrl/shift). Mouse gestures work, too, for those so
inclined.
--
Darin McGrew, mc****@stanfordalumni.org, http://www.rahul.net/mcgrew/
Web Design Group, da***@htmlhelp.com, http://www.HTMLHelp.com/

"When strong encryption is outlawed, only outlaws jvyy hfr fgebat rapelcgvba."

[Spartanicus]

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

Don't know about you, but I normally use the return key to submit
single-line forms.

Take a look at <http://www.w3.org/TR/REC-html40/interact/forms.html#h-17.8>.
In the suggested replacement for the (deprecated) ISINDEX element, you'll
see a form with no submit button. There are no accessibility or
user-friendliness issues with this technique that I am aware of.

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.

[1] Internal company use only, results are not public.

--
Spartanicus

[Philip Ronan]

"Darin McGrew" wrote:

Take a look at <http://www.w3.org/TR/REC-html40/interact/forms.html#h-17.8>.
In the suggested replacement for the (deprecated) ISINDEX element, you'll
see a form with no submit button. There are no accessibility or
user-friendliness issues with this technique that I am aware of.
The purpose of that example is to demonstrate a form that replicates the
deprecated ISINDEX element.

Yes indeed it is.
If you add a submit button, then you've added
something beyond what ISINDEX provides, and the example is less clear.

Pardon?

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

[Philip Ronan]

"Spartanicus" 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. Did
the buttonless search box in your study have any initial content?

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

[Alan J. Flavell]

On Wed, 6 Jul 2005, Philip Ronan wrote:

"Alan J. Flavell" wrote:

The inconsistency is only in your own mind. If you'd been paying
attention to any serious discussion on these principles, you wouldn't
be making such a silly claim.
Alan, earlier today you responded to my suggestion about using Javascript to
clear the initial contents of a search box as follows:

What's insecure is allowing an untrusted site to execute javascript on
one's browser. The intended purpose is irrelevant for this. If you
don't yet know this, then you aren't in a position to argue about it.

If you can't see the inconsistency between that statement and your
subsequent assertion that using Javascript to provide "extra conveniences"
is "fine"

I've already pointed you to resources which I'd say will confirm that
my advice is consistent with the general conclusions of informed
discussion here and in other relevant forums. If you're still
resistant to those then I see little point in arguing with you further
on a one to one basis.
then frankly there's not much point in me trying to continue a
logical discussion here.

Indeed.

bye

[Darin McGrew]

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

Take a look at <http://www.w3.org/TR/REC-html40/interact/forms.html#h-17.8>.
In the suggested replacement for the (deprecated) ISINDEX element, you'll
see a form with no submit button. There are no accessibility or
user-friendliness issues with this technique that I am aware of.

I wrote: The purpose of that example is to demonstrate a form that replicates the
deprecated ISINDEX element.
Philip Ronan <in*****@invalid.invalid> wrote:

Yes indeed it is. If you add a submit button, then you've added
something beyond what ISINDEX provides, and the example is less clear.

Pardon?

The example in the HTML 4 spec is not--nor was it intended to be--a good
example of an HTML form. It was intended to be an example of an HTML form
that replicates the deprecated ISINDEX functionality. Since ISINDEX doesn't
generate a submit button, the example form has no submit button.

If the example had included a submit button, then it would have been a
better example of a good HTML form. However, it would have been a worse
example of a form that merely replicates the deprecated ISINDEX
functionality.

Other forms shown in the HTML 4 spec, which are intended to be good
examples of an HTML form, do include submit buttons.
--
Darin McGrew, mc****@stanfordalumni.org, http://www.rahul.net/mcgrew/
Web Design Group, da***@htmlhelp.com, http://www.HTMLHelp.com/

"When strong encryption is outlawed, only outlaws jvyy hfr fgebat rapelcgvba."

[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*****@invalid.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.infosystems.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.com/faq/> JL/RC: FAQ of news:comp.lang.javascript
<URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demon.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 "bookmarklets" (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.infosystems.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
functionality 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.com/faq/> JL/RC: FAQ of news:comp.lang.javascript
<URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.