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]

in post <news:e4********************************@4ax.com >
Stephen Poley said:

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]
--
brucie
05/December/2003 05:37:51 pm kilo

[rf]

"Stephen Poley" <sb*****@xs4all.nl> wrote in message
news:e4********************************@4ax.com...

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 [phone]. 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

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

[Leif K-Brooks]

e n | c k m a wrote:

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]

Stephen Poley wrote:

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]

e n | c k m a wrote:

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)

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
<br******@bruciesusenetshit.info> wrote:

That was a quick response! Thanks.

in post <news:e4********************************@4ax.com >
Stephen Poley said:

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)

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.

--
Stephen Poley

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

[Richard Cornford]

"e n | c k m a" <bo*@marley.com> wrote in message
news:7F*****************@news-server.bigpond.net.au...
<snip>

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]

In article <0h******************@news-server.bigpond.net.au>,
ma**********@the.time says...

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

--
Whitecrest Entertainment
www.whitecrestent.com

[Stephen Poley]

On Fri, 05 Dec 2003 08:50:11 GMT, "e n | c k m a" <bo*@marley.com>
wrote:

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

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

[Stephen Poley]

On 5 Dec 2003 09:17:26 GMT, "Philipp Lenssen" <in**@outer-court.com>
wrote:

Stephen Poley wrote:

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.

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

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

[Stephen Poley]

On Fri, 05 Dec 2003 10:36:20 +0000, David Leverton <u0*****@abdn.ac.uk>
wrote:

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

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

[Stephen Poley]

On Fri, 05 Dec 2003 08:24:28 GMT, "rf" <ma**********@the.time> wrote:

"Stephen Poley" <sb*****@xs4all.nl> wrote in message
news:e4********************************@4ax.com.. .

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

Hnmm. What a terribly good idea.

And, what an excellent use of javascript - to *enhance* what is an already
working page.
Thanks.
<story> ....
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.

--
Stephen Poley

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

[Richard Cornford]

"Whitecrest" <wh********@zipzap.com> wrote in message
news:MP************************@news.charter.net.. .
<snip>

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]

In article <bq*******************@news.demon.co.uk>,
Ri*****@litotes.demon.co.uk says...

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

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.

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.

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
www.whitecrestent.com

[Frank Carr]

"Stephen Poley" <sb*****@xs4all.nl> wrote in message
news:e4********************************@4ax.com...

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.

--
Frank Carr
jf****@msn.com
http://www15.brinkster.com/vbnotebook

[Philipp Lenssen]

Stephen Poley wrote:

On 5 Dec 2003 09:17:26 GMT, "Philipp Lenssen" <in**@outer-court.com>
wrote:

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.

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.

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.

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]

JRS: In article <e4********************************@4ax.com>, seen in
news:comp.lang.javascript, Stephen Poley <sb*****@xs4all.nl> posted at
Fri, 5 Dec 2003 08:35:40 :-

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.

--
© 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.demon.co.uk/js-index.htm> JS maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/JS/&c., FAQ topics, links.

[Stephen Poley]

On Fri, 5 Dec 2003 11:15:44 -0000, "Richard Cornford"
<Ri*****@litotes.demon.co.uk> wrote:

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

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

JRS: In article <e4********************************@4ax.com>, seen in
news:comp.lang.javascript, Stephen Poley <sb*****@xs4all.nl> posted at
Fri, 5 Dec 2003 08:35:40 :-

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

I would be interested in comments, suggested improvements etc.

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.getElementById == 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 <20***************************@mb-m15.aol.com>, seen in
news:comp.lang.javascript, HikksNotAtHome <hi************@aol.com>
posted at Tue, 24 Jun 2003 21:37:32 :-
if(document.all && !document.getElementById) {
document.getElementById = function(id) {
return document.all[id];
}
}

--
© 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.demon.co.uk/js-index.htm> JS maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/JS/&c., FAQ topics, links.

[Richard Cornford]

"Stephen Poley" <sb*****@xs4all.nl> wrote in message
news:8a********************************@4ax.com...
<snip>

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.

From the commonCheck function:-

|if (document.getElementById == undefined)
| return true; // older browser - leave validation to the server
|var elem = document.getElementById(ifld);
|if (!elem.firstChild && !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.undefined = window.undefined;

- or -

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

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

if (!document.getElementById){
// 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.firstChild && !elem.innerHTML))

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

var elem;
if(!document.getElementById ||
((!(elem = document.getElementById(ifld)) ||
(!elem.firstChild && !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="validateTelnr(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="validateTelnr( 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.

[Lasse Reichstein Nielsen]

"Richard Cornford" <Ri*****@litotes.demon.co.uk> writes:

if (!elem || (!elem.firstChild && !elem.innerHTML))
I see two problems with testing for "innerHTML" in this way.

One is that the content of an element can be the empty string. In that
case, "!elem.innerHTML" is true, even though innerHTML is supported.
You can avoid that by testing for an element you know isn't empty,
otherwise, use
typeof elem.innerHTML == "string"
The point here is that .innerHTML is a string property, not an object
property, so testing for its existence should not be done by
converting it to a boolean (nor should it for other types that contain
"falsey" values).
The other problem is performance. This test reads the innerHTML
property of elem. If elem contains a lot of content, the DOM tree is
traversed to create the string returned. Not that much of a problem,
if it is only done once, but still.

The optimal test for the innerHTML property is:
"innerHTML" in elem
Sadly, it is only supported in recent browsers (don't know the exact
limit), and it is a syntax error in earlier browsers.

To avoid this syntax error, maybe you can include a function like
function myInTest(prop,obj) { return prop in obj; }
in a script element of its own. If there is a syntax error, only
that script element is affected (hopefully). It's not pretty, though,
and will give warning signs in some browsers.

(The obvious alternative, obj.hasOwnProperty doesn't work for
innerHTML in Opera. Apparently, innerHTML lies in a prototype, not in
the object itself).
As it stands this test will be executed upon every change made to a
field in the form.

do performance matters (or, as you suggest, a rewrite).

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

[Richard Cornford]

"Stephen Poley" <sb*****@xs4all.nl> wrote in message
news:8a********************************@4ax.com...

|if (!elem.firstChild && !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]

In article <76**************@merlyn.demon.co.uk>, one of infinite monkeys
at the keyboard of Dr John Stockton <sp**@merlyn.demon.co.uk> wrote:

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

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]

Stephen Poley wrote:

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

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]

On 5 Dec 2003 18:23:00 GMT, "Philipp Lenssen" <in**@outer-court.com>
wrote:

Stephen Poley wrote:

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.
I usually find response times of say 1 to 2 seconds OK.

Agreed. If you can provide a 2 second response via a 33K modem (or
thereabouts), then client-side validation is redundant.
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!

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]

On Fri, 05 Dec 2003 08:35:40 +0100, Stephen Poley <sb*****@xs4all.nl>
wrote:

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.

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]

On Sat, 6 Dec 2003 02:09:51 -0000, "Richard Cornford"
<Ri*****@litotes.demon.co.uk> wrote:

"Stephen Poley" <sb*****@xs4all.nl> wrote in message
news:8a********************************@4ax.com.. .

|if (!elem.firstChild && !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.

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.javascript FAQ - http://jibbering.com/faq/

[Dr John Stockton]

JRS: In article <ii********************************@4ax.com>, seen in
news:comp.lang.javascript, Stephen Poley <sb*****@xs4all.nl> posted at
Sat, 6 Dec 2003 09:27:39 :-

On 5 Dec 2003 18:23:00 GMT, "Philipp Lenssen" <in**@outer-court.com>
wrote:

Stephen Poley wrote:

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.

I usually find response times of say 1 to 2 seconds OK.

Agreed. If you can provide a 2 second response via a 33K modem (or
thereabouts), then client-side validation is redundant.

You cannot rely on doing that. The user may acquire the form while
connected, and want to fill it up at leisure then send it when next
connected. The user may be on a train, wireless-connected, and go into
a tunnel. You may, of course, feel that an unimportant case.

--
© 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.demon.co.uk/js-index.htm> JS maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/JS/&c., FAQ topics, links.

[Dr John Stockton]

JRS: In article <v6***********@jarl.webthing.com>, seen in
news:comp.lang.javascript, Nick Kew <ni**@fenris.webthing.com> posted at
Sat, 6 Dec 2003 02:34:07 :-

In article <76**************@merlyn.demon.co.uk>, one of infinite monkeys
at the keyboard of Dr John Stockton <sp**@merlyn.demon.co.uk> wrote:

W3's free TIDY said :

What version of Tidy? It looks rather old and it's made some bad mistakes.

A fairly recent one, for DOS. Unlike the one I used before, it has the
flaw of not identifying its version in its normal output. It's one
where two of the four instances of "sourceforge" in the EXE is actually
spelt "sourgeforge". EXE file dated 2003/02/27-13:49:16, fetched
2003/06/20-07:42:10.

line 9 column 5 - Warning: inserting "type" attribute for <link> element

Correct - provided it got the right type.

Not correct, actually; I was using TIDY in check-only mode, so
"inserting" is not really right.

line 101 column 1 - Warning: <table> lacks "summary" attribute

Yes - though a low-priority warning (required only for AAA compliance)

? Alcoholics Anonymous of Armenia
? Azerbaijani Automobile Association?
Probably not; but I do not recognise the initials, and I do recall being
advised that a summary should be provided by some probably-other source.
AIUI, it helps non-sighted users and similar.

line 180 column 1 - Warning: trimming empty <p>

Fair enough but not necessary.

line 104 column 9 - Warning: Attribute "size" not supported in HTML 4.01

That is seriously screwed - I'm surprised!

Agreed; but I use "<input size" myself, and TIDY accepts it ...
"less-than""letter" in script can confuse that Tidy; but I don't see it
present.

Info: Doctype given is "-//W3C//DTD HTML 4.01//EN"

Correct.

Info: Document content looks like HTML 4.01 Transitional

Nonsense. That's a known Tidy bug from pre-sourceforge days;
I thought it had been dealt with.

What, and where, is the latest TIDY for DOS? Mine is :

imports\tidy\tidy.exe -version
HTML Tidy for Windows released on 1st February 2003

A binary scan of the EXE for -version apparently finds 2 copies of the
text given by tidy -help !!

--
© 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.demon.co.uk/js-index.htm> JS maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/JS/&c., FAQ topics, links.

[Lasse Reichstein Nielsen]

Dr John Stockton <sp**@merlyn.demon.co.uk> writes:

Yes - though a low-priority warning (required only for AAA compliance)

? Alcoholics Anonymous of Armenia
? Azerbaijani Automobile Association?
Probably not; but I do not recognise the initials, and I do recall being
advised that a summary should be provided by some probably-other source.
AIUI, it helps non-sighted users and similar.

It refers to a W3C Recommendation for web content accessibility:
<URL:http://www.w3.org/TR/WAI-WEBCONTENT/>
Triple-A is the highest level of conformance.

I wouldn't have found it from just the letters "AAA" if I hand't known
that it was about accessibility. Adding that as a search word made
Google give a good link.

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

[Daniel R. Tobias]

"rf" <ma**********@the.time> wrote in message news:<0h******************@news-server.bigpond.net.au>...

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 [phone]. I lied again.

And then there are the sites that refuse to accept the fact that
da*@tobias.name is a valid e-mail address... some people still think
that top level domains are no longer than 3 letters long.

--
Dan

[Toby A Inkster]

Dr John Stockton wrote:

EXE file dated 2003/02/27-13:49:16, fetched 2003/06/20-07:42:10.

You missed out on the 2003/07/01 release by a week and a half.

--
Toby A Inkster BSc (Hons) ARCS
Contact Me - http://www.goddamn.co.uk/tobyink/?page=132

[Vigil]

Why does that background have to be static? Is it just me that is sent
into CPU overwork when a static bg is used? I've seen some sites have
plain monotonous colour static bgs - what's the point of that?

On Fri, 05 Dec 2003 08:35:40 +0100, Stephen Poley wrote:

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

--

..

[Dr John Stockton]

JRS: In article <pa****************************@privacy.net>, seen in
news:comp.lang.javascript, Vigil <[e-mail]> posted at Sun, 7 Dec
2003 16:20:58 :-

Why does that background have to be static? Is it just me that is sent
into CPU overwork when a static bg is used? I've seen some sites have
plain monotonous colour static bgs - what's the point of that?

On Fri, 05 Dec 2003 08:35:40 +0100, Stephen Poley wrote:

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

Any background other than a plain, light-coloured one, or one scarcely
distinguishable from that, is a handicap to at least some potential
readers. Using a patterned background demonstrates that the site is
intended to be admired, rather than to be read.

--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 MIME. ©
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
I find MiniTrue useful for viewing/searching/altering files, at a DOS prompt;
free, DOS/Win/UNIX, <URL:http://www.idiotsdelight.net/minitrue/> Update soon?

[Dr John Stockton]

JRS: In article <pa***************************@goddamn.co.uk>, seen in
news:comp.lang.javascript, Toby A Inkster <UseTheAddressInMySig@deadspam
..com> posted at Sun, 7 Dec 2003 11:29:13 :-

Dr John Stockton wrote:

EXE file dated 2003/02/27-13:49:16, fetched 2003/06/20-07:42:10.

You missed out on the 2003/07/01 release by a week and a half.

Drat. The distribution site appears to be down at present.

IIRC & IMHO, there is a flaw of omission in the distribution - in what
one actually fetches. It does not, or did not, include a small text or
HTML file saying which version it is and where it comes from. This
would be a useful reminder for those thinking of updating or
recommending.

--
© 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.demon.co.uk/js-index.htm> JS maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/JS/&c., FAQ topics, links.

[Lasse Reichstein Nielsen]

Dr John Stockton <sp**@merlyn.demon.co.uk> writes:

Any background other than a plain, light-coloured one, or one scarcely
distinguishable from that, is a handicap to at least some potential
readers. Using a patterned background demonstrates that the site is
intended to be admired, rather than to be read.

I'll second that (except that dark background with white text is also
usable, and possibly even easier to read than dark on light colors).

For maximal readability, the background should be a solid color, and
the foreground and background should have good contrast (preferably
one of them being black or white).

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

[Toby A Inkster]

Dr John Stockton wrote:

IIRC & IMHO, there is a flaw of omission in the distribution - in what
one actually fetches. It does not, or did not, include a small text or
HTML file saying which version it is and where it comes from.

Running "tidy -version" will tell you which version you are using.

The manual (on Linux, "man tidy") tells you where you can download new
versions.

--
Toby A Inkster BSc (Hons) ARCS
Contact Me - http://www.goddamn.co.uk/tobyink/?page=132

[Bart Lateur]

rf wrote:

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.

Whatever anybody else may think, IMO if something like a country is so
important as to it changes everything else, it shouldn't be on the same
form. Instead, it should be a choice you have to make upfront, on a
separate page.

--
Bart.

[Vigil]

But to have a small repeating bg static like that, that has the bonus
of sending the viewer's (my) CPU into overdrive... what's the point?

On Sun, 07 Dec 2003 18:30:22 +0000, Dr John Stockton wrote:

Any background other than a plain, light-coloured one, or one scarcely
distinguishable from that, is a handicap to at least some potential
readers. Using a patterned background demonstrates that the site is
intended to be admired, rather than to be read.

--

..

[Stephen Poley]

On Sat, 6 Dec 2003 00:51:21 -0000, "Richard Cornford"
<Ri*****@litotes.demon.co.uk> wrote:

"Stephen Poley" <sb*****@xs4all.nl> wrote in message
news:8a********************************@4ax.com.. .
<snip>

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.

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?).
I didn't know that. Thanks.
if (!document.getElementById){
// getElementById cannot be used.
}
- should be sufficient, and avoid any language version issues.
Agreed.
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.firstChild && !elem.innerHTML))
My feeling is that if an error can only be triggered by an *authoring*
mistake (such as mistyping an id) then it's probably better to let it
trigger a Javascript error which tells the author where to look, rather
than have it do nothing and leave one scratching ones head.
It would also be possible to combine the two tests into one - if -
statement:-

var elem;
if(!document.getElementById ||
((!(elem = document.getElementById(ifld)) ||
(!elem.firstChild && !elem.innerHTML)))){
return true; // leave validation to the server
}
True, but I prefer to avoid expressions that complicated (eight
operators of four kinds) where reasonably possible.
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.
That's worth knowing for future reference, but in this case I feel that
the repeated tests are so simple that the performance gain is unlikely
to be worth while.

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="validateTelnr(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.
I didn't realise that hadn't been standardised. Thanks. Using 'this' is
probably clearer anyway.

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

True - a slightly misguided attempt at humour.

Thank you again for your help.

--
Stephen Poley

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

[Stephen Poley]

On Sat, 6 Dec 2003 02:09:51 -0000, "Richard Cornford"
<Ri*****@litotes.demon.co.uk> wrote:

"Stephen Poley" <sb*****@xs4all.nl> wrote in message
news:8a********************************@4ax.com.. .

|if (!elem.firstChild && !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.

That would explain a problem I had in the early stages, which I
addressed by substituting a non-breaking space for an empty string in
the msg function. I've got both methods in now, as a spot of
belt-and-braces.

--
Stephen Poley

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

[Stephen Poley]

On Fri, 5 Dec 2003 23:38:13 +0000, Dr John Stockton
<sp**@merlyn.demon.co.uk> wrote:

JRS: In article <e4********************************@4ax.com>, seen in
news:comp.lang.javascript, Stephen Poley <sb*****@xs4all.nl> posted at
Fri, 5 Dec 2003 08:35:40 :-

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

I would be interested in comments, suggested improvements etc.

W3's free TIDY said :

line 9 column 5 - Warning: inserting "type" attribute for <link> element
Bit redundant, as the stylesheet is not specific to any particular media
type.
line 101 column 1 - Warning: <table> lacks "summary" attribute
Added.
line 180 column 1 - Warning: trimming empty <p>
There is no <p> at or near line 180
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
Incorrect, as pointed out by Nick.
The page currently lacks, AFAICS in MSIE 4 : Author name, date of
editing, links to homepage.
Links are (and were) present. Date added. I don't bother to put my name
on every page - maybe I could.
I entered xx in the first box; it thought a bit, and remarked "Line 66
Char 3 'undefined' is undefined"
This will be one of the points Richard raised. I didn't realise that
undefined was undefined (!) in the first few versions of Javascript.
(Line 66 does not hold script).
Yes, well - better talk to your browser supplier about that. <g>
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.
I think it reasonable to assume that the user understands that 'send'
will not do a great deal when offline.
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.
Interesting point. I think however that it is reasonable to expect that
anyone viewing HTML source should have an editor/viewer capable of
coping with longer lines. The script is already mostly less than 72
characters wide, with those lines which are longer being longer for a
reason.

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.
Fair enough.
The ostensible wording is good; there is a split infinitive in
formval.js <g>.
I decided to deliberately ignore this comment. <g>
I think formval.js Line 66 is :
if (document.getElementById == undefined)

Should that be "'undefined'"? I like using "var U" to define an
undefined variable ... but you could put "var undefined" ... .
See note above.
By using proceed instead of continu you could obviate a comment.
Agreed - done.
Your actual validity-testing could be shortened by using the approach of
my js-valid.htm .
Well, your code is certainly impressively brief. But I feel mine is
easier to understand, and also more flexible for e.g. putting up
warnings when an input is likely to be incorrect but is not definitely
so. Compactness is not as important as it used to be, with faster modems
and HTTP data-compression. Maybe still important for mobile connections
using 9.6 Kbps, but I'm not sure how many of those devices support
Javascript anyway.
IIRC, someone posted an implementation of getElementById for older
browsers in c.l.j a while ago. Yes, ...

Thanks, but on the whole I'd prefer to stick to standard Javascript
except where it's necessary to support a very widely used browser (i.e.
IE 5/6)

I've put up a new version of the page.

--
Stephen Poley

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

[Stephen Poley]

On Sun, 07 Dec 2003 16:20:58 +0000, Vigil <[e-mail]> wrote:

Why does that background have to be static?
It doesn't *have* to be, but I prefer the appearance of the scrolling
that way, especially when I have my window set to a large size.
Is it just me that is sent
into CPU overwork when a static bg is used?
I've had one person complain about that before; it turned out he was
running Netscape 7 / Mozilla (I forget which) on a machine slower than
the recommended minimum hardware configuration. What is your
configuration?
I've seen some sites have
plain monotonous colour static bgs - what's the point of that?

On Fri, 05 Dec 2003 08:35:40 +0100, Stephen Poley wrote:

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

--
Stephen Poley

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

[Toby A Inkster]

Stephen Poley wrote:

On Fri, 5 Dec 2003 23:38:13 +0000, Dr John Stockton
<sp**@merlyn.demon.co.uk> wrote:

W3's free TIDY said :

line 9 column 5 - Warning: inserting "type" attribute for <link> element

Bit redundant, as the stylesheet is not specific to any particular media
type.

@type isn't used for media types. For a CSS stylesheet, @type should be
set to "text/css".

@media is used for media types.

--
Toby A Inkster BSc (Hons) ARCS
Contact Me - http://www.goddamn.co.uk/tobyink/?page=132

[Richard Cornford]

"Jim Ley" <ji*@jibbering.com> wrote in message
news:3f****************@news.cis.dfn.de...
<snip>

I forgot to mention that the innerHTML test ...

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

The tests in question do seem to centre around whether the user will be
able to see[1] the error messages generated, and if not there isn't much
point in attempting the validation. So some additional checking to
ensure that error message reporting function really is modifying the
browser DOM does seem like a good idea.

[1] Sight, of course, brings us back to the problems of reporting
validation errors on screen readers that we kicked about a bit a couple
of months back.

Richard.

[Richard Cornford]

"Stephen Poley" <sb*****@xs4all.nl> wrote in message
news:j8********************************@4ax.com...
<snip>

... . 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.firstChild && !elem.innerHTML))
My feeling is that if an error can only be triggered by an
*authoring* mistake (such as mistyping an id) then it's probably
better to let it trigger a Javascript error which tells the
author where to look, rather than have it do nothing and leave
one scratching ones head.

Fair enough. In addition to authoring mistakes there is the (very)
slight possibility of the actions of a content re-writing/inserting
proxy modifying either the JS code or the ID attribute in passing, but
it would be insane to configure a proxy to do that so it would be
reasonable to argued that anyone who does so deserves what they would
get as a result.

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

var elem;
if(!document.getElementById ||
((!(elem = document.getElementById(ifld)) ||
(!elem.firstChild && !elem.innerHTML)))){
return true; // leave validation to the server
}

True, but I prefer to avoid expressions that complicated
(eight operators of four kinds) where reasonably possible.

That is probably a matter of perception, I don't see the expression as
complex while I do see the multiple (in excess of two) return statements
as ugly. But you are in a better position to judge when perceived
complexity becomes a maintenance burden with your own code.

<snip>

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

That's worth knowing for future reference, but in this
case I feel that the repeated tests are so simple that
the performance gain is unlikely to be worth while.

Yes, a script that is triggered in response to user actions like this
would have to be very poor before performance gains became a worthwhile
consideration. Personally, I like the degrade - don't degrade decision
to (where practical) be final, but that is just a matter of style. And I
would have been as likely to approach the problem form the other end and
only assigned the event handling functions with JavaScript after
confirming browser support for the features required by those functions.

<snip> Thank you again for your help.

You are welcome, and I generally applaud the intention of your page as
there is little that I consider more stupid than taking the intrinsic
reliability of the combination of HTML forms and server-side scripting
and making it dependent on client-side scripting (or worse, browser
specific client-side scripting). I remain undecided about some aspects
of the problem (mostly related to the behaviour of speech browsers and
especially screen readers) but I doubt that I would be able to move
towards drawing definite conclusions without more public debate on the
subject in general.

Richard.