Javascript form validation - comments please

[Stephen Poley]

I have quite often (as have probably many of you) come across HTML forms
with irritating bits of Javascript attached. The last straw on this
particular camel's back was a large form I was asked to complete in
connection with attendance at a seminar. After spending more than 15
minutes on it, I clicked on the submit button - and nothing happened.

Looking round the pages on Javascript form validation that Google
produced for me (well, 15-20 of them!), none seemed to emphasise the
points that I feel to be important. And some even advocated bad
practices. So I decided to stick my neck out and produce a page on how
it ought to be done:

http://www.xs4all.nl/~sbpoley/webmatters/formval.html

I would be interested in comments, suggested improvements etc. In
particular any cross-browser Javascript aspects I have overlooked.
(I've tried the page in Opera 7, Mozilla 1.1, IE 6, NN4).

 

[brucie]

I have quite often (as have probably many of you) come across HTML forms
with irritating bits of Javascript attached. The last straw on this
particular camel's back was a large form I was asked to complete in
connection with attendance at a seminar. After spending more than 15
minutes on it, I clicked on the submit button - and nothing happened.

in my experience thats normal behavior. i'm constantly amazed at how bad
form design is. the creators just don't think.

http://www.xs4all.nl/~sbpoley/webmatters/formval.html

very good. where you mention trailing whitespace you may like to add
line breaks as well which isn't uncommon when copy/pasting (recent
experience, took me ages to work out why my text was being rejected)

NS4.76: http://stuff.bruciesusenetshit.info/screencap09.png [35k]

 

[rf]

I have quite often (as have probably many of you) come across HTML forms
with irritating bits of Javascript attached. The last straw on this
particular camel's back was a large form I was asked to complete in
connection with attendance at a seminar. After spending more than 15
minutes on it, I clicked on the submit button - and nothing happened.

Looking round the pages on Javascript form validation that Google
produced for me (well, 15-20 of them!), none seemed to emphasise the
points that I feel to be important. And some even advocated bad
practices. So I decided to stick my neck out and produce a page on how
it ought to be done:

http://www.xs4all.nl/~sbpoley/webmatters/formval.html

I would be interested in comments, suggested improvements etc. In
particular any cross-browser Javascript aspects I have overlooked.
(I've tried the page in Opera 7, Mozilla 1.1, IE 6, NN4).

Hnmm. What a terribly good idea.

And, what an excellent use of javascript - to *enhance* what is an already
working page.

<story>
Came across some software I thought I might like. The demo download required
filling in a form with all the usual intrusive questions. Some twenty of
them.

Right at the bottom is the standard address fields with the <annoying> drop
down country selection </annoying>. So, having filled in the entire form I
change the country from the default USA (of course) to Australia.

Immediately a new "international" form fills my canvas, with, as you may
guess, all of the fields blank.

I found some more suitable software
</story>

<gripe>
You mention how much validation to do. I think you should add a section
giving some more examples of what *not* to do.

I was required to answer questions once on a computer at, of all places, a
ski rental shop in (you guessed it) the U S of A. Mammoth to be exact. This
computer insisted my postcode (they called it a zip code) had to be exactly
5 digits long. My postcode is 2154. Of course I lied.

Same form insisted my phone number must be of the form 555 555 555 (IIRC).
Mine is +61 2 5555 5555. I lied again.

Same form had an <annoying> drop down state selection </annoying>. NSW was
not in there, just things like CA, CO, NY etc. Needless to say I, and the
other 5 Australians with me, lied.

So much for their demographics
</gripe>

Cheers
Richard.

 

[e n | c k m a]

http://www.xs4all.nl/~sbpoley/webmatters/formval.html

I would be interested in comments, suggested improvements etc. In
particular any cross-browser Javascript aspects I have overlooked.
(I've tried the page in Opera 7, Mozilla 1.1, IE 6, NN4).

Very good idea - I was putting thought into a sign-up form i'm creating at
the moment and was thinking of adding features like focus changes and alert
boxes but decided against it because it annoys users and interferes with
their movements on the page... maybe you can work that in some how - unless
someone has any ideas as to why they should be included (ie. the alert box
in your first example form)

Nicko.

 

[e n | c k m a]

I would be interested in comments, suggested improvements etc. In

Very good idea - I was putting thought into a sign-up form i'm creating at
the moment and was thinking of adding features like focus changes and alert
boxes but decided against it because it annoys users and interferes with
their movements on the page... maybe you can work that in some how - unless
someone has any ideas as to why they should be included (ie. the alert box
in your first example form)

Also: "The detection of these older browsers is done by object detection,"

I think it's referred to as "method detection", isn't it? You're not really
detecting objects, but methods.

 

[Leif K-Brooks]

Also: "The detection of these older browsers is done by object detection,"

I think it's referred to as "method detection", isn't it? You're not really
detecting objects, but methods.

Methods are just a type of object in ECMAScript, IIRC.

 

[Philipp Lenssen]

http://www.xs4all.nl/~sbpoley/webmatters/formval.html

I would be interested in comments, suggested improvements etc. In
particular any cross-browser Javascript aspects I have overlooked.
(I've tried the page in Opera 7, Mozilla 1.1, IE 6, NN4).

Checking your sample form, I found it quite confusing the original
input information text (to the right-side) disappeared when you click
submit and get errors.

What I think is important is that validation data should only be stored
once, or else you would implement validation on the client and on the
server (and you would need to change two things for every change).

What I don't find optimal is that you need to debug for
JavaScript-enabled plus non-JavaScript browsers, with little to gain,
except maybe a split-second when it comes to replies.

 

[Matthias Gutfeldt]

Very good idea - I was putting thought into a sign-up form i'm creating at
the moment and was thinking of adding features like focus changes and alert
boxes but decided against it because it annoys users and interferes with
their movements on the page... maybe you can work that in some how - unless
someone has any ideas as to why they should be included (ie. the alert box
in your first example form)

Yeah, alert boxes are hell... you want to skip an item to fill it in
later. But the form throws an alert box at you and won't let you do it.
You CAN'T fill it in later - the alert box won't let you! This really
sucks, it's one of the most annoying 'features' I have found in forms.


Matthias

 

[David Leverton]

Stephen Poley wrote:
[snip]

http://www.xs4all.nl/~sbpoley/webmatters/formval.html

I would be interested in comments, suggested improvements etc. In
particular any cross-browser Javascript aspects I have overlooked.
(I've tried the page in Opera 7, Mozilla 1.1, IE 6, NN4).

Pretty good, the only problem I can see is that changing the messages
next to the form fields causes bits of the page to shift around (in Moz
1.5 and IE 6, at least), which is mildly annoying. Perhaps set a fixed
width and height for the relevant table cells (in CSS, with the em unit
so it adapts to the user's font size)?

 

[Stephen Poley]

On Fri, 5 Dec 2003 18:15:30 +1000, brucie

That was a quick response! Thanks.

in my experience thats normal behavior. i'm constantly amazed at how bad
form design is. the creators just don't think.


very good. where you mention trailing whitespace you may like to add
line breaks as well which isn't uncommon when copy/pasting (recent
experience, took me ages to work out why my text was being rejected)

Good point.

NS4.76: http://stuff.bruciesusenetshit.info/screencap09.png [35k]

<sound of head hitting wall> It was fine yesterday morning, and all
I've done since then is add a few lines of text. I guess I'm going to
give up and hide all my CSS from NN4, as is frequently recommended
around these parts.

 

[Richard Cornford]

Also: "The detection of these older browsers is done by object
detection,"

I think it's referred to as "method detection", isn't it? You're
not really detecting objects, but methods.

The most common alternative (and more precise) term for "object
detection" is "feature detection" as it takes into account that some of
the things that need detecting are not necessarily objects but may get
down to ECMA Script implementation details. Such as checking to see of
the String.replace method will accept a function reference as its second
argument (as is very usefully the case in later versions) with code
like:-

if('a'.replace(/a/, function(){return '';}).length == 0){
//function references OK.
}else{
//no function references with replace.
}

(it works because if only string arguments are accepted as the second
argument the function is type-converted into a string and that string
has a length longer than zero.)

However, the code in question does not use object/feature detecting in
the sense that the term is used in connection with cross-browser
scripting. It uses a technique that is best categorised as "object
inference". Testing for the existence of one method, in this case the
document.getElementById method, and then assuming that the presence of
that feature can be used to infer the existence of other features,
dynamic support of either innerHTML or the W3C DOM interfaces to the
level of text nodes.

The assumption that the existence of the document.getElementById method
can be used to infer that the browser has full dynamic display
capabilities falls down in the face of, for example, Opera 5 & 6 and Web
Browser 2 (on the Palm OS (based on NetFront)) which both implement the
method but do not implement either of the required interfaces. (Opera 6
puts up a JavaScript error message and Web Browser 2 just fails
quietly).

A feature/object detecting script would have gone to the effort of
verifying the existence of the required dynamic interfaces before
attempting to use them. Not that knowing that an element has a text node
as its firstChild necessarily means that writing to the nodeValue
property of its firstChild will result in changes in the display, but at
least knowing that the firstChild property is a reference to an object
prevents the attempt to write to one of its properties from putting up a
JavaScript error report.

The general principals of feature/object detecting is to verify the
existence (and possibly behaviour) of any feature that can be verified
prior to using it and make as few assumptions as possible. In that way a
feature/object detecting script can exploit a browser up to the browsers
ability to support the script and still be in a position to cleanly
degrade under its own control in the face of the absence of the required
features without ever needing to be interested in any of the specifics
of which browser it is that it is executing on.

On the other hand, object inference, to be effective, requires a
detailed knowledge of the DOM/ECMA Script implementations of every
version of every JavaScript capable web browser, knowledge that nobody
sane could reasonably claim to posses.

Richard.

 

[Whitecrest]

So, having filled in the entire form I
change the country from the default USA (of course) to Australia.
Immediately a new "international" form fills my canvas, with, as you may
guess, all of the fields blank.

You sound bitter, and I can feel you pain (ok I can't but I will
pretend I can) Was the company based in the US? If so, then having the
drop down default to US is perfectly acceptable. Now, making you start
off with a completely new form, I can see how that would piss you off.

But, even so, from what I am reading, you needed a product. You spent
time researching it, and decided that of all the products available,
this one was the best. Then you went to order it, had the form thing
(which has to happen to you in one way or another all the time).

So you decided that since you had to fill in a new international order
form, you would buy a different product that for some reason you had
recently decided was inferior to the one you were originally trying to
order.

Seems kind of silly to me, that is, to buy an inferior product because
some web developer did something you did not like. I probably would
have bought the product, then bitched to them, then tell them you will
not recommend their product to anyone.

But of course, that would mean more typing again....

I admire your conviction for the cause. But I (especially now as I
transition out of Web development and into other things), just would
have handled it a little differently...

 

[Stephen Poley]

Also: "The detection of these older browsers is done by object detection,"

I think it's referred to as "method detection", isn't it? You're not really
detecting objects, but methods.

I think you're right, but 'object detection' seems to be the generally
used term. Methods belong to objects, anyway.

 

[Stephen Poley]

Checking your sample form, I found it quite confusing the original
input information text (to the right-side) disappeared when you click
submit and get errors.

The intention is that the error text should supersede the original info
- i.e. contain everything the original text had, plus maybe a bit more.
I'll have another look at it.

What I think is important is that validation data should only be stored
once, or else you would implement validation on the client and on the
server (and you would need to change two things for every change).

Yes, you do end up with some duplication. It's a question of how much
you feel is worth investing to help the user. The point of the page
(perhaps I should review whether it comes over) is not so much that you
should use client-side validation, but that *if* you do so, do it
properly.

What I don't find optimal is that you need to debug for
JavaScript-enabled plus non-JavaScript browsers, with little to gain,
except maybe a split-second when it comes to replies.

Debugging for non-Javascript browsers is pretty trivial though. And once
you've got yourself a set of standard routines, adding validation to new
forms isn't much work.

As for the benefits: it depends. With a broadband connection and a fast
server there probably isn't much benefit. Sometimes however one has to
wait 10-20 seconds for a server response. With a more complex form
and/or a not-so-careful user, needing 2 or 3 bites at the cherry, it
could save the user quite a bit of time.

 

[Stephen Poley]

Stephen Poley wrote:
[snip]

http://www.xs4all.nl/~sbpoley/webmatters/formval.html

I would be interested in comments, suggested improvements etc. In
particular any cross-browser Javascript aspects I have overlooked.
(I've tried the page in Opera 7, Mozilla 1.1, IE 6, NN4).

Pretty good, the only problem I can see is that changing the messages
next to the form fields causes bits of the page to shift around (in Moz
1.5 and IE 6, at least), which is mildly annoying. Perhaps set a fixed
width and height for the relevant table cells (in CSS, with the em unit
so it adapts to the user's font size)?

Yes, I could have a go at fixing the width. A similar problem was
discussed a little while ago somewhere in c.i.w.a.*, where someone
wanted a table to remain fixed once the initial display was completed.
There doesn't seem to be a general solution, but with this simple table
it might be possible to do something better. I think the height is going
to vary though, as spacing all the rows out enough to accommodate the
largest error-message probably won't look good.

 

[Stephen Poley]

Hnmm. What a terribly good idea.

And, what an excellent use of javascript - to *enhance* what is an already
working page.
Thanks.

....

I found some more suitable software
</story>

Indeed. You wonder whether site owners have the slightest idea how many
people they are driving away.

<gripe>
You mention how much validation to do. I think you should add a section
giving some more examples of what *not* to do.

Yes, that could be a project in its own right. I think it would probably
be better as a separate page.

 

[Richard Cornford]

So you decided that since you had to fill in a new international
order form, you would buy a different product that for some
reason you had recently decided was inferior to the one you were
originally trying to order.

Seems kind of silly to me, that is, to buy an inferior product
because some web developer did something you did not like.

You seem to be assuming that any product has just one distinct source
when purchased online. That isn't really the case, usually it is
possible to find many outlets offering the same products, and frequently
at the same prices. So the decision to purchase from a different
retailer doesn't mean choosing an inferior product it just means that
the retailer who initially managed to get themselves to the top of
Richard's list (maybe through search engine order, maybe by conveying a
superior air of professionalism through their presentation or some such)
then knocked themselves off his list by manifesting incompetence in with
online ordering system. And choosing to avoid doing business with a
company that publicly demonstrates incompetence strikes me as a wise
decision, probably saving money on the long run.

I probably would have bought the product, then bitched to
them, then tell them you will not recommend their product to
anyone.

Some businesses might care about their reputation (though that would
suggest that they should choose to employ competent web developers in
the first place) other will just be happy to be banking your money.

Richard.

 

[Whitecrest]

You seem to be assuming that any product has just one distinct source
when purchased online....

A lot of assumptions here actually, you are assuming they he could by it
somewhere else. When information is not supplied, we all have to make
assumptions.

Some businesses might care about their reputation (though that would
suggest that they should choose to employ competent web developers in
the first place) other will just be happy to be banking your money.

Totally agree, but I got what I wanted, at the price I wanted, and I got
to bitch about it. Life is good....

 

[Frank Carr]

I would be interested in comments, suggested improvements etc. In
particular any cross-browser Javascript aspects I have overlooked.
(I've tried the page in Opera 7, Mozilla 1.1, IE 6, NN4).

I like your point #2 and #3 about alert boxes and onblur interrupting the
flow of the page. This is something I've preached against in the Visual
Basic community for some years (MsgBox's and LostFocus events there).

I like the idea of using the CSS class to define the error message style.
This is something I've been doing in a site I'm re-designing right now.

On the javascript/no-javascript thing...I've been kicking this one around
myself. Some of the requirements I have do call for a degree of client-side
interactivity. Since it isn't a big general e-commerce site and is mainly
intended for internal people and affiliated businesses to use, I don't think
I'll encounter a significant user problem since about 95% are using IE6 and
the rest Mozilla under Linux. However, I do agree about having a graceful
way to degrade. Any further suggestions in this area would be a helpful
addition to your article.

 

[Dr John Stockton]

JRS: In article <[email protected]>, seen in

Looking round the pages on Javascript form validation that Google
produced for me (well, 15-20 of them!),

Did it find <URL:http://www.merlyn.demon.co.uk/js-valid.htm> ? If not,
you might like to look there.

It demonstrates a code-efficient way of validating many entries, and
suggests that a RegExp is almost always the way to test an entry first.