Javascript form validation - comments please

[Dr John Stockton]

Re: Javascript form validation - comments please

JRS: In article <ii43tv4m3q0ltb gr2oudbnlps4k6l kbamq@4ax.com>, seen in
news:comp.lang. javascript, Stephen Poley <sbpoley@xs4all .nl> posted at
Sat, 6 Dec 2003 09:27:39 :-[color=blue]
>On 5 Dec 2003 18:23:00 GMT, "Philipp Lenssen" <info@outer-court.com>
>wrote:
>[color=green]
>>Stephen Poley wrote:
>>[color=darkred]
>>> 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]

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

[Dr John Stockton]

Re: Javascript form validation - comments please

JRS: In article <v6frqb.fb1.ln@ jarl.webthing.c om>, seen in
news:comp.lang. javascript, Nick Kew <nick@fenris.we bthing.com> posted at
Sat, 6 Dec 2003 02:34:07 :-[color=blue]
>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=green]
>> W3's free TIDY said :[/color]
>
>What version of Tidy? It looks rather old and it's made some bad mistakes.[/color]

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 "sourceforg e" in the EXE is actually
spelt "sourgeforg e". EXE file dated 2003/02/27-13:49:16, fetched
2003/06/20-07:42:10.

[color=blue][color=green]
>> line 9 column 5 - Warning: inserting "type" attribute for <link> element[/color]
>Correct - provided it got the right type.[/color]

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

[color=blue][color=green]
>> line 101 column 1 - Warning: <table> lacks "summary" attribute[/color]
>Yes - though a low-priority warning (required only for AAA compliance)[/color]

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

[color=blue][color=green]
>> line 180 column 1 - Warning: trimming empty <p>[/color]
>Fair enough but not necessary.
>[color=green]
>> line 104 column 9 - Warning: Attribute "size" not supported in HTML 4.01[/color]
>That is seriously screwed - I'm surprised![/color]

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.
[color=blue][color=green]
>> Info: Doctype given is "-//W3C//DTD HTML 4.01//EN"[/color]
>Correct.
>[color=green]
>> 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.[/color]


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

imports\tidy\ti dy.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.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.

[Lasse Reichstein Nielsen]

Re: Javascript form validation - comments please

Dr John Stockton <spam@merlyn.de mon.co.uk> writes:
[color=blue][color=green]
>>Yes - though a low-priority warning (required only for AAA compliance)[/color]
>
> ? 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.[/color]

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 - lrn@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleD OM.html>
'Faith without judgement merely degrades the spirit divine.'

[Daniel R. Tobias]

Re: Javascript form validation - comments please

"rf" <making.it.up@t he.time> wrote in message news:<0hXzb.404 01$aT.27703@new s-server.bigpond. net.au>...[color=blue]
> I was required to answer questions once on a computer at, of all places, a
> ski rental shop in (you guessed it) the U S of A. Mammoth to be exact. This
> computer insisted my postcode (they called it a zip code) had to be exactly
> 5 digits long. My postcode is 2154. Of course I lied.
>
> Same form insisted my phone number must be of the form 555 555 555 (IIRC).
> Mine is +61 2 5555 5555. I lied again.[/color]

And then there are the sites that refuse to accept the fact that
dan@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]

Re: Javascript form validation - comments please

Dr John Stockton wrote:
[color=blue]
> EXE file dated 2003/02/27-13:49:16, fetched 2003/06/20-07:42:10.[/color]

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]

Re: Javascript form validation - comments please

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

--

..

[Dr John Stockton]

Re: Javascript form validation - comments please

JRS: In article <pan.2003.12.07 .16.20.57.64379 6@privacy.net>, seen in
news:comp.lang. javascript, Vigil <me@privacy.net > posted at Sun, 7 Dec
2003 16:20:58 :-[color=blue]
>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:
>[color=green]
>> http://www.xs4all.nl/~sbpoley/webmatters/formval.html[/color]
>[/color]

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.demo n.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.idiotsdelig ht.net/minitrue/> Update soon?

[Dr John Stockton]

Re: Javascript form validation - comments please

JRS: In article <pan.2003.12.07 .11.29.08.53326 @goddamn.co.uk> , seen in
news:comp.lang. javascript, Toby A Inkster <UseTheAddressI nMySig@deadspam
..com> posted at Sun, 7 Dec 2003 11:29:13 :-[color=blue]
>Dr John Stockton wrote:
>[color=green]
>> EXE file dated 2003/02/27-13:49:16, fetched 2003/06/20-07:42:10.[/color]
>
>You missed out on the 2003/07/01 release by a week and a half.[/color]

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

[Lasse Reichstein Nielsen]

Re: Javascript form validation - comments please

Dr John Stockton <spam@merlyn.de mon.co.uk> writes:
[color=blue]
> 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.[/color]

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 - lrn@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleD OM.html>
'Faith without judgement merely degrades the spirit divine.'

[Toby A Inkster]

Re: Javascript form validation - comments please

Dr John Stockton wrote:
[color=blue]
> 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.[/color]

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]

Re: Javascript form validation - comments please

rf wrote:
[color=blue]
>Right at the bottom is the standard address fields with the <annoying> drop
>down country selection </annoying>. So, having filled in the entire form I
>change the country from the default USA (of course) to Australia.
>
>Immediately a new "internatio nal" form fills my canvas, with, as you may
>guess, all of the fields blank.[/color]

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]

Re: Javascript form validation - comments please

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

--

..

[Stephen Poley]

Re: Javascript form validation - comments please

On Sat, 6 Dec 2003 00:51:21 -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...
><snip>[color=green]
>>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][/color]

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

I didn't know that. Thanks.
[color=blue]
>if (!document.getE lementById){
> // getElementById cannot be used.
>}
>- should be sufficient, and avoid any language version issues.[/color]

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

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.
[color=blue]
>It would also be possible to combine the two tests into one - if -
>statement:-
>
>var elem;
>if(!document.g etElementById ||
> ((!(elem = document.getEle mentById(ifld)) ||
> (!elem.firstChi ld && !elem.innerHTML )))){
> return true; // leave validation to the server
>}[/color]

True, but I prefer to avoid expressions that complicated (eight
operators of four kinds) where reasonably possible.
[color=blue]
> the onchange handler
>for the corresponding form field could be permanently disabled by
>assigning null to its onchnge property:-
>
>vfld.onchang e = null; //future change events will
> //not be calling JavaScript.[/color]

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.

[color=blue]
>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.
>Unfortunatel y, these behaviours are non-standardised and inconsistently
>implemented, there are also browsers that will do neither and - telnr -
>will remain undefined.[/color]

I didn't realise that hadn't been standardised. Thanks. Using 'this' is
probably clearer anyway.

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

True - a slightly misguided attempt at humour.

Thank you again for your help.

--
Stephen Poley

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

[Stephen Poley]

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

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]

Re: Javascript form validation - comments please

On Fri, 5 Dec 2003 23:38:13 +0000, Dr John Stockton
<spam@merlyn.de mon.co.uk> wrote:
[color=blue]
>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=green]
>>
>>http://www.xs4all.nl/~sbpoley/webmatters/formval.html
>>
>>I would be interested in comments, suggested improvements etc.[/color][/color]
[color=blue]
>W3's free TIDY said :
>
>line 9 column 5 - Warning: inserting "type" attribute for <link> element[/color]

Bit redundant, as the stylesheet is not specific to any particular media
type.
[color=blue]
>line 101 column 1 - Warning: <table> lacks "summary" attribute[/color]

Added.
[color=blue]
>line 180 column 1 - Warning: trimming empty <p>[/color]

There is no <p> at or near line 180
[color=blue]
>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[/color]

Incorrect, as pointed out by Nick.
[color=blue]
>The page currently lacks, AFAICS in MSIE 4 : Author name, date of
>editing, links to homepage.[/color]

Links are (and were) present. Date added. I don't bother to put my name
on every page - maybe I could.
[color=blue]
>I entered xx in the first box; it thought a bit, and remarked "Line 66
>Char 3 'undefined' is undefined"[/color]

This will be one of the points Richard raised. I didn't realise that
undefined was undefined (!) in the first few versions of Javascript.
[color=blue]
> (Line 66 does not hold script).[/color]

Yes, well - better talk to your browser supplier about that. <g>
[color=blue]
>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.[/color]

I think it reasonable to assume that the user understands that 'send'
will not do a great deal when offline.
[color=blue]
>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.[/color]

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.

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

Fair enough.
[color=blue]
>The ostensible wording is good; there is a split infinitive in
>formval.js <g>.[/color]

I decided to deliberately ignore this comment. <g>
[color=blue]
>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" ... .[/color]

See note above.
[color=blue]
>By using proceed instead of continu you could obviate a comment.[/color]

Agreed - done.
[color=blue]
>Your actual validity-testing could be shortened by using the approach of
>my js-valid.htm .[/color]

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.
[color=blue]
>IIRC, someone posted an implementation of getElementById for older
>browsers in c.l.j a while ago. Yes, ...[/color]

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/