Javascript form validation - comments please

[Stephen Poley]

Re: Javascript form validation - comments please

On Fri, 05 Dec 2003 08:24:28 GMT, "rf" <making.it.up@t he.time> wrote:
[color=blue]
>"Stephen Poley" <sbpoley@xs4all .nl> wrote in message
>news:e4d0tvcdp gst9etpqcbvkq4u dsb917crk4@4ax. com...[color=green]
>> 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
>>[/color][/color]
[color=blue]
>Hnmm. What a terribly good idea.
>
>And, what an excellent use of javascript - to *enhance* what is an already
>working page.[/color]

Thanks.
[color=blue]
><story>[/color]
....
[color=blue]
>I found some more suitable software :-)
></story>[/color]

Indeed. You wonder whether site owners have the slightest idea how many
people they are driving away.
[color=blue]
><gripe>
>You mention how much validation to do. I think you should add a section
>giving some more examples of what *not* to do.[/color]

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

--
Stephen Poley

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

[Richard Cornford]

Re: Javascript form validation - comments please

"Whitecrest " <whitecrest@zip zap.com> wrote in message
news:MPG.1a3a3e f69177b10b9898e 6@news.charter. net...
<snip>[color=blue]
>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.[/color]

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.
[color=blue]
>I probably would have bought the product, then bitched to
>them, then tell them you will not recommend their product to
>anyone.[/color]

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]

Re: Javascript form validation - comments please

In article <bqpv26$7kg$1$8 302bc10@news.de mon.co.uk>,
Richard@litotes .demon.co.uk says...[color=blue][color=green]
> >Seems kind of silly to me, that is, to buy an inferior product
> >because some web developer did something you did not like.[/color]
> You seem to be assuming that any product has just one distinct source
> when purchased online....[/color]

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.
[color=blue][color=green]
> >I probably would have bought the product, then bitched to
> >them, then tell them you will not recommend their product to
> >anyone.[/color]
> 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.[/color]

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

--
Whitecrest Entertainment

https://www.whitecrestent.com

[Frank Carr]

Re: Javascript form validation - comments please

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

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.

--
Frank Carr
jfcarr@msn.com

http://www15.brinkster.com/vbnotebook

[Philipp Lenssen]

Re: Javascript form validation - comments please

Stephen Poley wrote:
[color=blue]
> On 5 Dec 2003 09:17:26 GMT, "Philipp Lenssen" <info@outer-court.com>
> wrote:
>[/color]
[color=blue]
>[color=green]
> >What I think is important is that validation data should only be[/color]
> 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.
>[/color]

You don't necessarily end up with duplication; e.g. you could store the
patterns, mandatory fields, default-values etc. inside XML on the
server and create the JavaScript code dynamically.
On Windows, you could even use JScript in ASP to have parts of the same
code sit around on the server and the client.
[color=blue]
>
> 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.[/color]

I usually find response times of say 1 to 2 seconds OK. Of course when
it would take 20 seconds for a server response that's bad. But let's
say the validation is complex, then you _must_ do it on the server.
Imagine you want the user to enter his street adress and city and you
want to validate if that's a real street by comparing with your server
database. To do the same validation on the client would mean writing a
lot of code and send the data to the client. This might take much
longer than 20 seconds to download! (Besides, you might not want to
share the data.)
And then you have to do it all again on the server-side because you
don't know if the user has JavaScript!

[Dr John Stockton]

Re: Javascript form validation - comments please

JRS: In article <e4d0tvcdpgst9e tpqcbvkq4udsb91 7crk4@4ax.com>, seen in
news:comp.lang. javascript, Stephen Poley <sbpoley@xs4all .nl> posted at
Fri, 5 Dec 2003 08:35:40 :-[color=blue]
>
>Looking round the pages on Javascript form validation that Google
>produced for me (well, 15-20 of them!),[/color]

Did it find <URL:http://www.merlyn.demo n.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.

--
© John Stockton, Surrey, UK. ?@merlyn.demon. co.uk Turnpike v4.00 IE 4 ©
<URL:http://jibbering.com/faq/> Jim Ley's FAQ for news:comp.lang. javascript
<URL:http://www.merlyn.demo n.co.uk/js-index.htm> JS maths, dates, sources.
<URL:http://www.merlyn.demo n.co.uk/> TP/BP/Delphi/JS/&c., FAQ topics, links.

[Stephen Poley]

Re: Javascript form validation - comments please

On Fri, 5 Dec 2003 11:15:44 -0000, "Richard Cornford"
<Richard@litote s.demon.co.uk> wrote:
[color=blue]
>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.[/color]

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

<snip>

OK you have a good point here - though you make it in a rather
roundabout fashion - that I've missed a trick or two on the
feature/object detection front. (It's not a feature-inference script,
it's a defective feature-detecting script. ;-P )

I've added a couple of tests to the commonCheck routine. I'd be grateful
if you could give it a quick look and see if there's anything else I've
missed.

--
Stephen Poley

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

[Dr John Stockton]

Re: Javascript form validation - comments please

JRS: In article <e4d0tvcdpgst9e tpqcbvkq4udsb91 7crk4@4ax.com>, seen in
news:comp.lang. javascript, Stephen Poley <sbpoley@xs4all .nl> posted at
Fri, 5 Dec 2003 08:35:40 :-[color=blue]
>
>http://www.xs4all.nl/~sbpoley/webmatters/formval.html
>
>I would be interested in comments, suggested improvements etc.[/color]


W3's free TIDY said :

line 9 column 5 - Warning: inserting "type" attribute for <link> element
line 101 column 1 - Warning: <table> lacks "summary" attribute
line 180 column 1 - Warning: trimming empty <p>
line 104 column 9 - Warning: Attribute "size" not supported in HTML 4.01
line 111 column 9 - Warning: Attribute "size" not supported in HTML 4.01
line 118 column 9 - Warning: Attribute "size" not supported in HTML 4.01
line 125 column 9 - Warning: Attribute "size" not supported in HTML 4.01
Info: Doctype given is "-//W3C//DTD HTML 4.01//EN"
Info: Document content looks like HTML 4.01 Transitional
7 warnings, 0 errors were found!

....


I do not like patterned backgrounds; but yours is not too bad.

The page currently lacks, AFAICS in MSIE 4 : Author name, date of
editing, links to homepage.

I entered xx in the first box; it thought a bit, and remarked "Line 66
Char 3 'undefined' is undefined" (Line 66 does not hold script). This
appears to be all that it will do, except that the Send button also
tries to contact your Web site - without success, as I am offline. You
could add, apart from the ostensible form, a control to adapt behaviour
for off-line use.

You invite source viewing. Since you do not know what it will be viewed
with, ISTM that both HTML and script should be formatted for a
72-character right margin.

I would change the NOSCRIPT to acknowledge that enabling may be
impossible - ... "disabled" -> "not enabled" & "If you can enable it
...." is perhaps adequate but not ideal.

The ostensible wording is good; there is a split infinitive in
formval.js <g>.

I think formval.js Line 66 is :
if (document.getEl ementById == undefined)

Should that be "'undefined '"? I like using "var U" to define an
undefined variable ... but you could put "var undefined" ... .

By using proceed instead of continu you could obviate a comment.

Your actual validity-testing could be shortened by using the approach of
my js-valid.htm .

IIRC, someone posted an implementation of getElementById for older
browsers in c.l.j a while ago. Yes, ...

In article <20030624173732 .17796.00001037 @mb-m15.aol.com>, seen in
news:comp.lang. javascript, HikksNotAtHome <hikksnotathome @aol.com>
posted at Tue, 24 Jun 2003 21:37:32 :-[color=blue]
>
>if(document.al l && !document.getEl ementById) {
> document.getEle mentById = function(id) {
> return document.all[id];
> }
>}[/color]


--
© John Stockton, Surrey, UK. ?@merlyn.demon. co.uk Turnpike v4.00 IE 4 ©
<URL:http://jibbering.com/faq/> Jim Ley's FAQ for news:comp.lang. javascript
<URL:http://www.merlyn.demo n.co.uk/js-index.htm> JS maths, dates, sources.
<URL:http://www.merlyn.demo n.co.uk/> TP/BP/Delphi/JS/&c., FAQ topics, links.

[Richard Cornford]

Re: Javascript form validation - comments please

"Stephen Poley" <sbpoley@xs4all .nl> wrote in message
news:8aq1tv8pig nda65op83sl7ec8 bnucev9e1@4ax.c om...
<snip>[color=blue]
>I've added a couple of tests to the commonCheck routine.
>I'd be grateful if you could give it a quick look and see
>if there's anything else I've missed.[/color]

From the commonCheck function:-

|if (document.getEl ementById == undefined)
| return true; // older browser - leave validation to the server
|var elem = document.getEle mentById(ifld);
|if (!elem.firstChi ld && !elem.innerHTML )
| return true; // older browser

The first thing that struck me about this was the comparison with -
undefined - in the first test. undefined was introduced with JavaScript
1.3 but didn't make it into JScript until 5.0 (or maybe 5.5?). Which
makes me think that it probably should not be used in a test that is
intended to allow the script to degrade cleanly on older browsers, IE 4,
for example, will produce an (unhelpful) "undefined is undefined" error.
There are techniques that render undefined safe to use in any
environment, such as:-

window.undefine d = window.undefine d;

- or -

this.undefined = this.undefined; //executed in a global context.

- but they are probably not necessary as a type-converting test:-

if (!document.getE lementById){
// getElementById cannot be used.
}

- should be sufficient, and avoid any language version issues.

The value returned from the call to getElementById and assigned to the
local variable - elem - is not checked. Because you know that you have
put an element into the document with a corresponding ID attribute it
seems reasonable to assume that the function call will return a
reference to that element. But it doesn't cost much to double check, and
if the element was not returned you can be guaranteed that the message
writing function will not work. So:-

if (!elem || (!elem.firstChi ld && !elem.innerHTML ))

It would also be possible to combine the two tests into one - if -
statement:-

var elem;
if(!document.ge tElementById ||
((!(elem = document.getEle mentById(ifld)) ||
(!elem.firstChi ld && !elem.innerHTML )))){
return true; // leave validation to the server
}

It is worth baring in mind that this is a test to avoid executing the
script on browsers that cannot support it, some of these will be "older
browsers" but others will the latest versions of non-dynamic browsers
such as some of those found on small PDAs and cell phones.

As it stands this test will be executed upon every change made to a
field in the form. If the browser fails on the first attempt it will
also fail on all subsequent attempts so it might be worth ensuring that
the test is not needlessly repeated once it has failed. I notice that
the - commonCheck - function is expecting to have a reference to the
invoking form element passed to it as its - vfld - parameter. As a
result, having identified an unsupporting browser, the onchange handler
for the corresponding form field could be permanently disabled by
assigning null to its onchnge property:-

vfld.onchange = null; //future change events will
//not be calling JavaScript.

(knocking onsubmit out from the FORM element is also an option).

Other alternatives might include replacing the - commonCheck - function
with another that did nothing but return true, short-circuiting all
subsequent testing.

Looking at the ONCHANGE attributes in your HTML to verify the origin of
the - vfld - parameter I notice that you are using an unreliable
accessor to pass the reference to the form element:-

| <INPUT TYPE=text NAME="telnr"
| ID="telnr" SIZE="35" MAXLENGTH="25"
| ONCHANGE="valid ateTelnr(telnr, 'inf_telnr', true);">

The identifier - telnr - is being used to pass the reference to INPUT
element to the - validateTelnr - function. Many browsers provide the
functions generated with event handling attribute strings with custom
scope handling mechanisms that will resolve the identifier - telnr - as
a named property of the form, others provide named form elements as
named properties of the global object so scope resolution will find the
right object under the name - telnr - at the end of the scope chain.
Unfortunately, these behaviours are non-standardised and inconsistently
implemented, there are also browsers that will do neither and - telnr -
will remain undefined.

However, the JavaScript language requires that when a function is
invoked as a method of an object the - this - keyword is always a
reference to that object, and event handling functions are always
invoked as methods of the element with which they are associated. That
means that event handling attribute code can always refer to the element
to which it is attached with the - this - keyword and so pass on
references to that element, while side-stepping the inconsistencies in
scope resolution from (internally generated) event handling functions:-

ONCHANGE="valid ateTelnr( this, 'inf_telnr', true);">

Nothing else stands out as potentially problematic, though I don't think
that you should be commenting on people managing to survive for more
than 100 years, I would put the cut-off point at around 125. Anyone who
has made it past 100 is unlikely to appreciate the comment "Getting on a
bit, aren't you?".

Richard.

[Richard Cornford]

Re: Javascript form validation - comments please

"Stephen Poley" <sbpoley@xs4all .nl> wrote in message
news:8aq1tv8pig nda65op83sl7ec8 bnucev9e1@4ax.c om...

|if (!elem.firstChi ld && !elem.innerHTML )

I forgot to mention that the innerHTML test may not be the best as empty
strings type-convert to boolean false, so - !elem.innerHTML - will be
true if the innerHTML string exists but is empty. That is not a problem
with your original HTML page as none of the relevant elements are
initially empty but generally a test for the lack of support for
innerHTML might be best done with - (typeof elem.innerHTML !=
"string") - as that relationship is unaffected by the content of the
innerHTML string (if it exists). This might be relevant to your code as
some of the functions are setting innerHTML to an empty string.

Richard.

[Nick Kew]

Re: Javascript form validation - comments please

In article <763SiDJlbR0$Ew Rn@merlyn.demon .co.uk>, one of infinite monkeys
at the keyboard of Dr John Stockton <spam@merlyn.de mon.co.uk> wrote:
[color=blue]
> W3's free TIDY said :[/color]

What version of Tidy? It looks rather old and it's made some bad mistakes.[color=blue]
>
> line 9 column 5 - Warning: inserting "type" attribute for <link> element[/color]
Correct - provided it got the right type.
[color=blue]
> line 101 column 1 - Warning: <table> lacks "summary" attribute[/color]
Yes - though a low-priority warning (required only for AAA compliance)
[color=blue]
> line 180 column 1 - Warning: trimming empty <p>[/color]
Fair enough but not necessary.
[color=blue]
> line 104 column 9 - Warning: Attribute "size" not supported in HTML 4.01[/color]
That is seriously screwed - I'm surprised!
[color=blue]
> Info: Doctype given is "-//W3C//DTD HTML 4.01//EN"[/color]
Correct.
[color=blue]
> Info: Document content looks like HTML 4.01 Transitional[/color]
Nonsense. That's a known Tidy bug from pre-sourceforge days;
I thought it had been dealt with.

--
Nick Kew

In urgent need of paying work - see http://www.webthing.com/~nick/cv.html

[Nico Schuyt]

Re: Javascript form validation - comments please

Stephen Poley wrote:[color=blue]
> http://www.xs4all.nl/~sbpoley/webmatters/formval.html[/color]

Nice! But why still apply js when the server side testing is so complete?
IMO the form should :
- use cookies to prevent people have to fill in all the fields again next
time
- send a copy of the mail to the sender (I hate to make copies myself or not
knowing later what exactly I submitted)
Nico

[Stephen Poley]

Re: Javascript form validation - comments please

On 5 Dec 2003 18:23:00 GMT, "Philipp Lenssen" <info@outer-court.com>
wrote:
[color=blue]
>Stephen Poley wrote:
>[color=green]
>> 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.[/color]
>
>I usually find response times of say 1 to 2 seconds OK.[/color]

Agreed. If you can provide a 2 second response via a 33K modem (or
thereabouts), then client-side validation is redundant.
[color=blue]
>Of course when
>it would take 20 seconds for a server response that's bad. But let's
>say the validation is complex, then you _must_ do it on the server.
>Imagine you want the user to enter his street adress and city and you
>want to validate if that's a real street by comparing with your server
>database. To do the same validation on the client would mean writing a
>lot of code and send the data to the client. This might take much
>longer than 20 seconds to download![/color]

No argument from me there - indeed I make a comment on the page roughly
to that effect. But you might help the user by doing a quick client-side
check that a street name has indeed been filled in, and that it looks at
least a bit like a street name (rather than, say, just a house number).

--
Stephen Poley

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

[Stephen Poley]

Re: Javascript form validation - comments please

On Fri, 05 Dec 2003 08:35:40 +0100, Stephen Poley <sbpoley@xs4all .nl>
wrote:
[color=blue]
>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.[/color]


Thank you to everyone for the comments, especially the very detailed
comments from Richard and Dr John. I will work my way through them and
put up an improved page in a few days time.

--
Stephen Poley

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

[Jim Ley]

Re: Javascript form validation - comments please

On Sat, 6 Dec 2003 02:09:51 -0000, "Richard Cornford"
<Richard@litote s.demon.co.uk> wrote:
[color=blue]
>"Stephen Poley" <sbpoley@xs4all .nl> wrote in message
>news:8aq1tv8pi gnda65op83sl7ec 8bnucev9e1@4ax. com...
>
>|if (!elem.firstChi ld && !elem.innerHTML )
>
>I forgot to mention that the innerHTML test may not be the best as empty
>strings type-convert to boolean false, so - !elem.innerHTML - will be
>true if the innerHTML string exists but is empty.[/color]

I don't like innerHTML for a different reason... that is it could be
read-only or whatever, so if you're going to test to see if changing
innerHTML works you can do it with

foo.innerHTML=' <b>Chickens</b>'

if (foo.childNodes etc. or whatever non innerHTML methods you prefer
to test the existence of elements.

Jim.
--
comp.lang.javas cript FAQ - http://jibbering.com/faq/