DATE and TEXTAREA question

[daniel kaplan]

hello all,

am new to HTML and am in the process of creating a form, no serious
headaches, but am stumped on two types of fields. i can take care of these
situations using javascript, but was adviced to only use javascript only
when absolutely necessary, so am trying to find to see if i can handle these
situations in HTML only.
TEXTAREA field
maxlength isn't doing anything, is there a solution?

DATE
is there a way to create a DATE field that only accepts numbers and "/". i
have found tons of sites that say input="date" or date="mm/dd/yyyy", but
they do nothing!

if in the end i have to do all my validating via javascript or server side,
so be it, but wanted to check out here first.

many thanks ahead of time,

daniel

[David Dorward]

daniel kaplan wrote:

am new to HTML and am in the process of creating a form, no serious
While writing words entirely in capital letters is an accepted form of
emphasis, they should also be used to start sentences. It makes it rather
harder to read a message which lacks capitals in the usual places, so
please help us to help you.
headaches, but am stumped on two types of fields. i can take care of
these situations using javascript, but was adviced to only use javascript
only when absolutely necessary
JavaScript is not something that should be used only when there is no other
way. It can be used for many things, but should never be _depended_ upon
(and generally shouldn't be used when the effect can be achieved in plain
HTML 4.01 Strict or CSS).
TEXTAREA field
maxlength isn't doing anything, is there a solution? DATE
is there a way to create a DATE field that only accepts numbers and "/".

There is nothing in HTML to enforce the format of text entered into a
textarea field, nor is there anything to suggest a maximum length of a
textarea. JavaScript could be used in both these cases to aid the user in
entering data to fit the requirements of the system.

Even the HTML suggestions are only suggestions, there is nothing actively
preventing the user from entering whatever data they like - so you should
*always* perform sanity checking of incoming data on the server.

On the subject of the date, my preferred method for handling this type of
thing is a normal text input for the user to enter the date. Next to this I
(having checked that the browser supports enough JavaScript, CSS and DOM to
handle it) I place a calendar icon set to fire off a JSCalendar[1] which
writes the date out in an unambiguous format[2]. On the server I then run
the date through Date::Parse[3] which can cope with most date formats a
user might choose to use.

[1] http://www.dynarch.com/projects/calendar/
[2] e.g. 12th Dec 2004
[3] http://search.cpan.org/~gbarr/TimeDa.../Date/Parse.pm

--
David Dorward <http://blog.dorward.me.uk/> <http://dorward.me.uk/>
Home is where the ~/.bashrc is

[Michael Winter]

On Sun, 12 Dec 2004 17:10:24 -0500, daniel kaplan <no****@nospam.com>
wrote:

[snip]

i can take care of these situations using javascript, but was
adviced to only use javascript only when absolutely necessary,
You can use client-side scripting as often as you like. The caveat is that
you must not *rely* on it (at least on the Web) to perform validation or
provide critical functionality (like navigation). You can use Javascript
to validate a form, but that validation should be replicated on the server.

[snip]
TEXTAREA field
maxlength isn't doing anything, is there a solution?
There is no maxlength attribute for TEXTAREA elements. You'll have to
check the length of the string on submission.
DATE
is there a way to create a DATE field that only accepts numbers and "/".
No.
i have found tons of sites that say input="date" or date="mm/dd/yyyy",
but they do nothing!

Then tons of sites contain complete rubbish (nothing unusual there, then).
:) Again, it's something you'll have to validate yourself, though be
careful with using locale-specific date formats if you'll draw audiences
from other countries.

[snip]

Mike

--
Michael Winter
Replace ".invalid" with ".uk" to reply by e-mail.

[daniel kaplan]

"David Dorward" <do*****@yahoo.com> wrote in message
news:cp*******************@news.demon.co.uk...

[many things]

Thanks for your help, if i may ask a follow up:

Woudl it be wiser to use BOTH JS and server-side to validate the data? I
mean sure, I could use JS to do that, but then wiseguys (i assume) could
manipulte outgoing data, and then lets face it, not validating at the server
side would just be crazy.

So my thoughts are, validate at the client-side (using JS) to elminate 95%
of server-side processing time, by catching innocent mistakes, and then
still validate at server-side to prevent the trouble makers.

Woudl my thinking be correct here?

Thanks agaiun,

daniel

[David Dorward]

daniel kaplan wrote:

Woudl it be wiser to use BOTH JS and server-side to validate the data?

I thought I've covered this in my previous post, but rereading it I find
that I only implied it, so here goes:

If its important the the data you receive fit a certain format (and it very
often is, even if only to avoid losing data that won't fit in the given
space in a database column) then you *should* perform some form of check on
the server and return an error message (or maybe just a wanring) to the
user if it fails.

*Optionally*, after[1] you have written the server side code, you can look
at providing some client side check (using the maxlength attribute and/or
JavaScript) as a *convenience* to the user so that they can receive the
afore mentioned error or warning without having to spend time watching
their form submission make a round trip to the server and come back with
errors.

[1] You could do it before, but leaving it until after helps avoid lazyness
and accidently dependency on the client side code.

--
David Dorward <http://blog.dorward.me.uk/> <http://dorward.me.uk/>
Home is where the ~/.bashrc is

[Alan J. Flavell]

On Sun, 12 Dec 2004, Michael Winter wrote:

You can use Javascript to validate a form,
agreed, but as you say, there's no certainty it'll get executed
but that validation should be replicated on the server.
Oh, I'd put it stronger than that. Any form which does something of
any significance *must* get its input validated on the server. It
would be insane to miss that out.

But that's a topic for itself (c.i.w.a.cgi would be the usual
recommendation - beware the automoderator bot) and not really
something that should be discussed in any depth here on *.html

i have found tons of sites that say input="date" or
date="mm/dd/yyyy", but they do nothing!

You'd be in luck today...
Again, it's something you'll have to validate yourself, though be
careful with using locale-specific date formats if you'll draw
audiences from other countries.

Absolutely!

[Stephen Poley]

On Sun, 12 Dec 2004 17:10:24 -0500, "daniel kaplan" <no****@nospam.com>
wrote:

am new to HTML and am in the process of creating a form, no serious
headaches, but am stumped on two types of fields. i can take care of these
situations using javascript, but was adviced to only use javascript only
when absolutely necessary, so am trying to find to see if i can handle these
situations in HTML only.

You may find this helpful:
http://www.xs4all.nl/~sbpoley/webmatters/formval.html

--
Stephen Poley

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

[Dr John Stockton]

JRS: In article <Pi*******************************@ppepc56.ph.gla. ac.uk

, dated Sun, 12 Dec 2004 23:50:26, seen in news:comp.infosystems.www.au thoring.html, Alan J. Flavell <fl*****@ph.gla.ac.uk> posted :On Sun, 12 Dec 2004, Michael Winter wrote:

You can use Javascript to validate a form,

agreed, but as you say, there's no certainty it'll get executed

but that validation should be replicated on the server.

Oh, I'd put it stronger than that. Any form which does something of
any significance *must* get its input validated on the server. It
would be insane to miss that out.

Only if there is a server that accepts form input; and if any possible
response from the form could inconvenience the proprietor of the
service.

My host offers only a few pre-programmed responses; but, if it did allow
me to write server-side processing, I would not want to look at the
results; my only concern would be that there could be nothing resembling
a Denial-of-Service attack. If a user were to choose to submit garbage,
then he would get garbage back.

Of course, you may say that my pages should not be using forms. They
were recommended to me as a means, in effect, of scoping HTML
identifiers; please feel free to explain anything that would be better.
But at present they are forms.

I'm reasonably sure that Michael meant that, for data with external
effect server-side, reliance on client validation is inadequate; and
that input must be validated by receiving-system code whenever validity
matters to the receiver.

--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4 ©
<URL:http://www.jibbering.com/faq/> JL/RC: FAQ of news:comp.lang.javascript
<URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.