Prevent user from entering punctuation

[PW]

Hi,

Is there anyway to format a text input so the user cant enter punctuation
marks?

TIA,
PW

 

[tbar]

www.pixar.com

 

[Jonathan N. Little]

Hi,

Is there anyway to format a text input so the user cant enter punctuation
marks?

Before it is posted, your can use JavaScript to check the input, but
that is no guarantee because the user may have JavaScript disabled. You
should *always* check user input upon the receiving end at the
server-side script. There is where you can make the final and absolute
check of the input. You can either quietly filter out the unwanted
characters or return to then previous form with an error message.

 

[tbar]

Isn't Disney bound to a 3d thing for xmas

 

[Beauregard T. Shagnasty]

Isn't Disney bound to a 3d thing for xmas

Ok. You've discovered Usenet. Now go away until you realize just what it
is.

 

[PW]

Yeah, thats what I was afraid of.

Thanks for the info,
PW

 

[Jonathan N. Little]

Ok. You've discovered Usenet. Now go away until you realize just what it
is.

Well, he thinks he's being clever,

 

[Blinky the Shark]

Ok. You've discovered Usenet. Now go away until you realize just what it
is.

BtS encouraging it, as usual.

 

[Jukka K. Korpela]

Before it is posted, your can use JavaScript to check the input, but
that is no guarantee because the user may have JavaScript disabled.
You should *always* check user input upon the receiving end at the
server-side script.

In this particular case, the check should probably be made _only_ in the
server.

As a rule, it is a good idea to consider setting up client-side checking as
well, after you have designed and implemented the server-side check.
Immediate checking is good for usability and accessibility: the user gets an
error message at an early phase where he remembers what he just did and has
the context and position in front of his years, literally or figuratively.

However, double checking tends to be expensive in terms of implementation
and maintenance work. You normally use two quite different programming
languages, JavaScript for client-side checking and something else for
server-side checking. This means duplicate coding; only the overall logic is
the same. Moreover, any changes need to be implemented twice, and this means
that some day you (or you successor as the maintainer) will forget this.
Testing needs to be duplicated, too - with scripting enabled and scripting
disabled. Testing the client-side checking is problematic, since there are
differences between browsers in JavaScript implementations.

So although it is a good idea to _consider_ client-side checking, due
consideration does not that often lead to _implementation_ of client-side
checking. In this particular case, the problem is particular hard. It is
much harder than people naively think, since they typically imply the ASCII
character repertoire.

A well-designed form handler is prepared to anything, including any Unicode
character in input data, since there is no reliable way to prevent users
from inputing any character, intentionally or accidentally. And when your
data is Unicode data, the question "what is a punctuation character?" is far
from trivial. Apparently e.g. Arabic triple dot punctuation mark and Greek
ano teleia and Tibetan mark tsheg shad are punctuation marks, right? Would
you even include all characters with a General Category value starting with
"P"? And no other? That would be a technically simple definition, and you
could write the check using a suitable function in a suitable subroutine
library - if you use an advanced programming language. But would that really
match what you want it to match?

My point here is that you probably want to define a _positive_ rule (which
characters are allowed) rather than a negative rule (which characters are
not allowed). The rule should correspond to the repertoire of characters
that your form handler and other software and data formats involved are
prepared to handle. There's no point in accepting a character on input if it
will be lost or distorted in the actual processing, e.g. when saving to a
database.

 

[code_wrong]

Hi,

Is there anyway to format a text input so the user cant enter punctuation
marks?

what's wrong with punctuation?

 

[Jonathan N. Little]

In this particular case, the check should probably be made _only_ in the
server.

As a rule, it is a good idea to consider setting up client-side checking
as well, after you have designed and implemented the server-side check.
Immediate checking is good for usability and accessibility: the user
gets an error message at an early phase where he remembers what he just
did and has the context and position in front of his years, literally or
figuratively.

However, double checking tends to be expensive in terms of
implementation and maintenance work. You normally use two quite
different programming languages, JavaScript for client-side checking and
something else for server-side checking. This means duplicate coding;
only the overall logic is the same. Moreover, any changes need to be
implemented twice, and this means that some day you (or you successor as
the maintainer) will forget this. Testing needs to be duplicated, too -
with scripting enabled and scripting disabled. Testing the client-side
checking is problematic, since there are differences between browsers in
JavaScript implementations.

I agree that it makes more work for the designer, but the benefit is
that it can give an advance tip to the user. I see benefit is
accommodating the user. If you make it more convenient or accessible for
them the more likely you will get their business! On dialup from
experience it can be a real pisser to only discover your error after you
posted the form and will have to do the process all over again.

On the implementation side I took the time to create a pair of script
PHP and JavaScript , I created an validation class object in each and
the base validation is set in my PHP and the PHP object creates upon
loading the document the JavaScript to load the same checking values
into the JavaScript object to keep everything synced. It was worth the
initial effort so now I only have to include the PHP class and attach
the JavaScript class then in the doc setup up the PHP object. The rest
is done automatically and if the user has JavaScript enabled client-side
checking will be enabled.

What one must be careful of it that their JavaScript validation does not
cause an endless loop when can happen with improper blur|focus handling...