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).

--
Stephen Poley

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

[brucie]

Re: Javascript form validation - comments please

in post <news:e4d0tvcdp gst9etpqcbvkq4u dsb917crk4@4ax. com>
Stephen Poley said:
[color=blue]
> 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.[/color]

in my experience thats normal behavior. i'm constantly amazed at how bad
form design is. the creators just don't think.
[color=blue]
> http://www.xs4all.nl/~sbpoley/webmatters/formval.html[/color]

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]


--
brucie
05/December/2003 05:37:51 pm kilo

[rf]

Re: Javascript form validation - comments please


"Stephen Poley" <sbpoley@xs4all .nl> wrote in message
news:e4d0tvcdpg st9etpqcbvkq4ud sb917crk4@4ax.c om...[color=blue]
> 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).[/color]

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 "internatio nal" 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]

Re: Javascript form validation - comments please

> http://www.xs4all.nl/~sbpoley/webmatters/formval.html[color=blue]
>
> 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).[/color]

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]

Re: Javascript form validation - comments please

> > I would be interested in comments, suggested improvements etc. In[color=blue][color=green]
> > particular any cross-browser Javascript aspects I have overlooked.
> > (I've tried the page in Opera 7, Mozilla 1.1, IE 6, NN4).[/color]
>
> 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[/color]
alert[color=blue]
> 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 -[/color]
unless[color=blue]
> someone has any ideas as to why they should be included (ie. the alert box
> in your first example form)[/color]

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.
[color=blue]
> Nicko.[/color]

[Leif K-Brooks]

Re: Javascript form validation - comments please

e n | c k m a wrote:[color=blue]
> 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.[/color]

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

[Philipp Lenssen]

Re: Javascript form validation - comments please

Stephen Poley wrote:
[color=blue]
>
> 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).[/color]

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]

Re: Javascript form validation - comments please

e n | c k m a wrote:[color=blue][color=green]
>>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).[/color]
>
>
> 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)[/color]

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]

Re: Javascript form validation - comments please

Stephen Poley wrote:
[snip][color=blue]
> 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).[/color]

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]

Re: Javascript form validation - comments please

On Fri, 5 Dec 2003 18:15:30 +1000, brucie
<brucie01@bruci esusenetshit.in fo> wrote:

That was a quick response! Thanks.
[color=blue]
>in post <news:e4d0tvcdp gst9etpqcbvkq4u dsb917crk4@4ax. com>
>Stephen Poley said:
>[color=green]
>> 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.[/color]
>
>in my experience thats normal behavior. i'm constantly amazed at how bad
>form design is. the creators just don't think.
>[color=green]
>> http://www.xs4all.nl/~sbpoley/webmatters/formval.html[/color]
>
>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)[/color]

Good point.
[color=blue]
>NS4.76: http://stuff.bruciesusenetshit.info/screencap09.png [35k][/color]

<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.

--
Stephen Poley

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

[Richard Cornford]

Re: Javascript form validation - comments please

"e n | c k m a" <bob@marley.com > wrote in message
news:7FXzb.4043 0$aT.2231@news-server.bigpond. net.au...
<snip>[color=blue]
>Also: "The detection of these older browsers is done by object
>detection,"[/color]
[color=blue]
>I think it's referred to as "method detection", isn't it? You're
>not really detecting objects, but methods.[/color]

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(){retu rn '';}).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.getEle mentById 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.getEle mentById 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]

Re: Javascript form validation - comments please

In article <0hXzb.40401$aT .27703@news-server.bigpond. net.au>,
making.it.up@th e.time says...[color=blue]
> So, having filled in the entire form I
> change the country from the default USA (of course) to Australia.
> Immediately a new "internatio nal" form fills my canvas, with, as you may
> guess, all of the fields blank.[/color]

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...

--
Whitecrest Entertainment

https://www.whitecrestent.com

[Stephen Poley]

Re: Javascript form validation - comments please

On Fri, 05 Dec 2003 08:50:11 GMT, "e n | c k m a" <bob@marley.com >
wrote:
[color=blue]
>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.[/color]

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

--
Stephen Poley

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

[Stephen Poley]

Re: Javascript form validation - comments please

On 5 Dec 2003 09:17:26 GMT, "Philipp Lenssen" <info@outer-court.com>
wrote:
[color=blue]
>Stephen Poley wrote:
>[color=green]
>> 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).[/color]
>
>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.[/color]

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.
[color=blue]
>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).[/color]

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.
[color=blue]
>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.[/color]

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

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

[Stephen Poley]

Re: Javascript form validation - comments please

On Fri, 05 Dec 2003 10:36:20 +0000, David Leverton <u01drl3@abdn.a c.uk>
wrote:
[color=blue]
>Stephen Poley wrote:
>[snip][color=green]
>> 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).[/color]
>
>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)?[/color]

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

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