Javascript form validation - comments please

[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/

[Stephen Poley]

Re: Javascript form validation - comments please

On Sun, 07 Dec 2003 16:20:58 +0000, Vigil <me@privacy.net > wrote:
[color=blue]
>Why does that background have to be static?[/color]

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.
[color=blue]
>Is it just me that is sent
>into CPU overwork when a static bg is used?[/color]

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

--
Stephen Poley

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

[Toby A Inkster]

Re: Javascript form validation - comments please

Stephen Poley wrote:
[color=blue]
> On Fri, 5 Dec 2003 23:38:13 +0000, Dr John Stockton
> <spam@merlyn.de mon.co.uk> wrote:
>[color=green]
>>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]

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

Re: Javascript form validation - comments please

"Jim Ley" <jim@jibbering. com> wrote in message
news:3fd1fee5.3 57100533@news.c is.dfn.de...
<snip>[color=blue][color=green]
>>I forgot to mention that the innerHTML test ...[/color][/color]
<snip>[color=blue]
>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.[/color]

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]

Re: Javascript form validation - comments please

"Stephen Poley" <sbpoley@xs4all .nl> wrote in message
news:j8h8tvoskr jpq44n72416c4mc pq7qvo0ed@4ax.c om...
<snip>[color=blue][color=green]
>>... . 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]

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.
[color=blue][color=green]
>>It would also be possible to combine the two tests into one
>>- if - statement:-
>>
>>var elem;
>>if(!document. getElementById ||
>> ((!(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]

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>[color=blue][color=green]
>>vfld.onchan ge = 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]

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>[color=blue]
> Thank you again for your help.[/color]

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.

[Dr John Stockton]

Re: Javascript form validation - comments please

JRS: In article <3cbwnogv.fsf@h otpop.com>, seen in
news:comp.lang. javascript, Lasse Reichstein Nielsen <lrn@hotpop.com >
posted at Mon, 8 Dec 2003 01:27:12 :-
[color=blue]
>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).[/color]

For ordinary, informative, bulk text, the words should be dark-on-light;
that is what readers have been accustomed to since ink-on-papyrus and
even soot-on-cave-wall. Light-on-dark is legible, but only suitable in
small blocks that need to be distinctive.

--
© 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]
> For ordinary, informative, bulk text, the words should be dark-on-light;
> that is what readers have been accustomed to since ink-on-papyrus and
> even soot-on-cave-wall.[/color]

It's not really that important, as long as the design is consistent.
People will read light-on-dark text without thinking twice without
thinking twice. I see many message boards using such a setup, where
a news site will probably want to look more like a newspaper.

The difference between a screen and ink-on-papyrus is that the screen
is back-lit. That makes black-on-white more straining on the eyes.
[color=blue]
> Light-on-dark is legible, but only suitable in small blocks that
> need to be distinctive.[/color]

I can't find a reference for it, but I believe it's actually *more*
legible than dark-on-light on a back-lit screen.

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

[Dr John Stockton]

Re: Javascript form validation - comments please

JRS: In article <pan.2003.12.08 .07.35.14.88670 3@goddamn.co.uk >, seen in
news:comp.lang. javascript, Toby A Inkster <UseTheAddressI nMySig@deadspam
..com> posted at Mon, 8 Dec 2003 07:35:20 :-[color=blue]
>Dr John Stockton wrote:
>[color=green]
>> 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.[/color]


But the distribution does not include the manual; hence, the small file
should also refer to obtaining the manual.

--
© 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 <4d59tvcagb17vr bgbbvdoddt7pt7h vlkp4@4ax.com>, seen in
news:comp.lang. javascript, Stephen Poley <sbpoley@xs4all .nl> posted at
Mon, 8 Dec 2003 16:16:34 :-[color=blue]
>On Fri, 5 Dec 2003 23:38:13 +0000, Dr John Stockton
><spam@merlyn.d emon.co.uk> wrote:[/color]
[color=blue][color=green]
>>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]

AFAICS in IE4, where "see" does not include reading the source.


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

Certainly; but it could be useful, since Send merely transmits something
to be ignored, to provide a means whereby a user can play with it when
off-line without generating unnecessary errors.
[color=blue][color=green]
>>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]

I only have 72-character eyeballs; and, if one may be citing line
number, it's nice to be sure that it is the same number as the author
sees. But it all depends on what tools the author uses. Editing with
PFE, I can pack a paragraph rapidly. Granted, it's hard to avoid all
long lines.

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

There is also the point that, in larger forms, the author does not have
to handle great lengths of repetitive stuff.

I'd not thought of warnings. As is, the object that defines a line has
two entries that do testing; optional entries for tests with different
responses could be added. Certainly, it is intended as a demonstration
to be adapted for actual use, and I've just added words to that effect.

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

[Toby A Inkster]

Re: Javascript form validation - comments please

Dr John Stockton wrote:
[color=blue]
> But the distribution does not include the manual;[/color]

Mine did.

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

[Stephen Poley]

Re: Javascript form validation - comments please

On Mon, 08 Dec 2003 18:30:05 +0000, Toby A Inkster
<UseTheAddressI nMySig@deadspam .com> wrote:
[color=blue]
>Stephen Poley wrote:
>[color=green]
>> On Fri, 5 Dec 2003 23:38:13 +0000, Dr John Stockton
>> <spam@merlyn.de mon.co.uk> wrote:
>>[color=darkred]
>>>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][/color]
[color=blue]
>@type isn't used for media types. For a CSS stylesheet, @type should be
>set to "text/css".
>
>@media is used for media types.[/color]

Hmm ... I think we both had our brains idling here. The issue is the
type attribute of the link element. I managed to completely misread the
relevant bit of the HTML spec; you appear to be thinking of a different
spec entirely. '@type'?

What I would have said if my brain had been in gear at the time
(assuming it now is):

Bit redundant, as the type of the stylesheet is primarily defined by the
HTTP headers (at least, I have heard this claimed often enough that I'm
inclined to believe it - must study the RFCs myself one day). Presumably
this attribute only saves browsers from retrieving stylesheets they
don't understand, and I don't think there are any web-browsers in the
wild which handle stylesheets but not CSS - are there?

--
Stephen Poley

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

[Vigil]

Re: Javascript form validation - comments please

Hmm. I am using Opera 7.23 on an Athlon XP 2something. I have also checked
with the Mozillas and MSIE in WinXP (same machine). Always the CPU load
goes up. Try running a CPU load monitor and yours should too.
Alternatively, make a test page without the static bg and put them side by
side, scroll each and you might notice the static bg page is slightly less
smooth (depending on your CPU, of course). I've heard it reported that it
does it on all browsers.

On Mon, 08 Dec 2003 16:16:35 +0100, Stephen Poley wrote:
[color=blue][color=green]
>>Is it just me that is sent
>>into CPU overwork when a static bg is used?[/color]
>
> 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?[/color]

--

..

[Tux]

On a slightly different topic

I want to produce a form for competition entry which would need minimal
editing from year to year. Since the entrants to the competition would have
to have birthdates between certain limits I would want to calculate these
and add the results to a selection list, something like

<select>
<option>Under-10 (born 1994 to 1996</option>
<option>Under-12 (born 1992 or 1993</option>

etc.

where the option values would include some javascript, e.g.

<option>Under-10
<script type="text/javascript">
document.write( " (born " + u10Lower + " to " + u10Upper + ")");
</script>
</option>

I have limited access to server side scripting, hence the reason for doing
it on the client side.

However, scripting seems to be illegal within an <option> tag. Does anyone
have any idea how I could do this?

--
Colin Walls
Extract the michael to mail me

[Lee]

Re: On a slightly different topic

Tux said:[color=blue]
>
>I want to produce a form for competition entry which would need minimal
>editing from year to year. Since the entrants to the competition would have
>to have birthdates between certain limits I would want to calculate these
>and add the results to a selection list, something like
>
><select>
><option>Unde r-10 (born 1994 to 1996</option>
><option>Unde r-12 (born 1992 or 1993</option>
>
>etc.
>
>where the option values would include some javascript, e.g.
>
><option>Unde r-10
> <script type="text/javascript">
> document.write( " (born " + u10Lower + " to " + u10Upper + ")");
> </script>
></option>
>
>I have limited access to server side scripting, hence the reason for doing
>it on the client side.
>
>However, scripting seems to be illegal within an <option> tag. Does anyone
>have any idea how I could do this?[/color]

Think through it a little bit more.

If a person was born in a certain year, that doesn't tell you
how old they are now. You need their complete birthdate for
that, which calls for a different sort of input element.

How many visitors do you expect to have who will know the year
in which the entrant was born, but won't know their age?
Why not simply:

<option>age 9 or 10</option>
<option>age 11 or 12</option>

[Toby A Inkster]

Re: Javascript form validation - comments please

Stephen Poley wrote:
[color=blue]
> '@type'?[/color]

Short for 'the attribute "type"'. This derives from the XPath spec.

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