what is <form> useful for?

[^AndreA^]

hello guys,

I've got a curiosity...

If I want to do a form with plain HTML and a scripting server-side
(such as php) I'd write something like this:

<form name="input" action="plain_html_form.php" method="post" >
Username:
<input type="text" name="user"> <br />
Email:
<input type="text" name="email"> <br />

<input type="submit" value="Submit"> <br />
</form>

and then from php I'll get the parameters as $_POST['user'] and
$_POST['email'] and that's alright...


BUT, if instead, I want to check the parameters before to send them to
the server, as I usually I do, I would use javascript...

With javascript I usually check if the fields are filled up correctly
and then I let javascript send them to the server, so I don't use the
form tag becuase I don't need it.

Is this method wrong?

Are there any downside I don't know?

thank you in advance,

Andrea

 

[Jonathan N. Little]

hello guys,

I've got a curiosity...

If I want to do a form with plain HTML and a scripting server-side
(such as php) I'd write something like this:

<form name="input" action="plain_html_form.php" method="post" >
Username:
<input type="text" name="user"> <br />
Email:
<input type="text" name="email"> <br />

<input type="submit" value="Submit"> <br />
</form>

and then from php I'll get the parameters as $_POST['user'] and
$_POST['email'] and that's alright...


BUT, if instead, I want to check the parameters before to send them to
the server, as I usually I do, I would use javascript...

With javascript I usually check if the fields are filled up correctly
and then I let javascript send them to the server, so I don't use the
form tag becuase I don't need it.

Is this method wrong?

Are there any downside I don't know?

And when JavaScript is disabled?

 

[Travis Newbury]

And when JavaScript is disabled?

Then it breaks and the visitor has a decision to make...

 

[Adrienne Boswell]

hello guys,

I've got a curiosity...

If I want to do a form with plain HTML and a scripting server-side
(such as php) I'd write something like this:

<form name="input" action="plain_html_form.php" method="post" >
Username:
<input type="text" name="user"> <br />
Email:
<input type="text" name="email"> <br />

<input type="submit" value="Submit"> <br />
</form>

and then from php I'll get the parameters as $_POST['user'] and
$_POST['email'] and that's alright...


BUT, if instead, I want to check the parameters before to send them to
the server, as I usually I do, I would use javascript...

With javascript I usually check if the fields are filled up correctly
and then I let javascript send them to the server, so I don't use the
form tag becuase I don't need it.

Is this method wrong?

You still need the form element. Certain elements, eg. input, cannot
exist without being wrapped in a form element. Javascript is nice as an
enhancement. As you know, you have to validate server side, especially
before you put anything in a db.

Are there any downside I don't know?

Yes, users with javascript disabled will submit to the value of the
action attribute. If you do not use the form element, there is no place
to submit to.

Again, it is very important to check everything server side, especially
when the data is going into a db. You might want to look into SQL
injection.

 

[Jonathan N. Little]

Then it breaks and the visitor has a decision to make...

Poor choice of design implementation.

 

[dorayme]

Poor choice of design implementation.

Actually, where Travis is concerned, good on you, Jonathan, in getting
the good message out there. He is hoping we will tire and he will get
his post-modernist/free-market/each-to-his-own take on objectivity to
swamp the battlefield.

 

[Art Sackett]

You might want to look into SQL injection.

I dunno... I still prefer sipping Jack Daniel's to injecting SQL. I have
this thing about needles...

 

[viza]

With javascript I usually check if the fields are filled up correctly
and then I let javascript send them to the server, so I don't use the
form tag becuase I don't need it.

An html compliant browser will not allow any input/textarea tags it
encounters if it has not already seen a form opening tag.

 

[Harlan Messinger]

An html compliant browser will not allow any input/textarea tags it
encounters if it has not already seen a form opening tag.

Not so:

<!ENTITY % formctrl "INPUT | SELECT | TEXTAREA | LABEL | BUTTON">

<!ENTITY % inline "#PCDATA | %fontstyle; | %phrase; | %special; |
%formctrl;">

Input and textarea tags can appear anywhere inline data can appear (or
flow data, because flow includes inline), with the exception of inside a
button (because of

<!ELEMENT BUTTON - -
(%flow* -(A|%formctrl;|FORM|FIELDSET)

).

 

[^AndreA^]

very good discussion guys, thank you to everyone...

So, I have understood that I need the form tag even though I choose
not to support users with javascript off.

I've also understood that is a good practice guarantee access to
people with javascript off (about 5% now, http://www.w3schools.com/browsers/browsers_stats.asp).

I "lost" the whole morning surfing the web trying to understand what
other people think about js on or off... ;-)

I usually check client-side for all of this stuff:
!@#$%^&*()+=[]\\\';,/{}|\":<>?~`.- _£

and then, if everything is fine, I send the data to php and I do just:
$_something = htmlentities($_POST['something']);

and then it's ready to be stored on the db.

Wasn't it enough?

Anyway It's useless to have a double check (client-side and server-
side), so, following your ideas I should do just a server side check
but it isn't as cool as AJAX...

Or maybe I could;
CLIENT-SIDE: check if the fields are filled up correctly (so who has
js on can find it usefull) and
SERVER-SIDE: check again all the fields and, above all, look for some
characters for security reasons.

What do you think?

Cheers,
Andrea

 

[Harlan Messinger]

very good discussion guys, thank you to everyone...

So, I have understood that I need the form tag even though I choose
not to support users with javascript off.

I've also understood that is a good practice guarantee access to
people with javascript off (about 5% now, http://www.w3schools.com/browsers/browsers_stats.asp).

I "lost" the whole morning surfing the web trying to understand what
other people think about js on or off... ;-)

I usually check client-side for all of this stuff:
!@#$%^&*()+=[]\\\';,/{}|\":<>?~`.- _£

and then, if everything is fine, I send the data to php and I do just:
$_something = htmlentities($_POST['something']);

and then it's ready to be stored on the db.

Wasn't it enough?

Anyway It's useless to have a double check (client-side and server-
side), so, following your ideas I should do just a server side check
but it isn't as cool as AJAX...

Or maybe I could;
CLIENT-SIDE: check if the fields are filled up correctly (so who has
js on can find it usefull) and
SERVER-SIDE: check again all the fields and, above all, look for some
characters for security reasons.

You should always check everything on the server side because clicking a
button on an unaltered page provided by you is not the only way someone
can submit data to your PHP process, so you can't be 100% certain that
the data that arrives at your server has already been checked. If the
AJAX is cool, great, but then to be on the safe side you should check in
both places.

 

[Travis Newbury]

Actually, where Travis is concerned, good on you, Jonathan, in getting
the good message out there. He is hoping we will tire and he will get
his post-modernist/free-market/each-to-his-own take on objectivity to
swamp the battlefield.

There you go again dorayme, telling someone what I was thinking. You
haven't a clue what I am thinking. I simply stated that when a
visitor comes to a page that is not configured for their browser, they
have to make a choice. Change the browser, or go away.

 

[Art Sackett]

I usually check client-side for all of this stuff:
!@#$%^&*()+=[]\\\';,/{}|\":<>?~`.- _£

It's safer to test for what you'll explicitly allow rather than what will
explicitly reject. For example, if you know that there's no reason for a
particular input to contain anything except [a-zA-Z0-9] then explicitly
allow only those rather than explicitly reject everything you can think
of that's not those things.

Or maybe I could;
CLIENT-SIDE: check if the fields are filled up correctly (so who has js
on can find it usefull) and
SERVER-SIDE: check again all the fields and, above all, look for some
characters for security reasons.

What do you think?

Sounds about right, but again permit only safe characters rather than
hoping to block all the bad ones.

 

[Jonathan N. Little]

There you go again dorayme, telling someone what I was thinking. You
haven't a clue what I am thinking. I simply stated that when a
visitor comes to a page that is not configured for their browser, they
have to make a choice. Change the browser, or go away.

And my point is there is and|or should be a certain level of competency
in web design. Sure you can find an autobody shop that employ duct
tape and spray-paint repairs, but doesn't make them competent, and I
certainly you not advocate the methodology.

 

[Jonathan N. Little]

very good discussion guys, thank you to everyone...

So, I have understood that I need the form tag even though I choose
not to support users with javascript off.

I've also understood that is a good practice guarantee access to
people with javascript off (about 5% now, http://www.w3schools.com/browsers/browsers_stats.asp).

I "lost" the whole morning surfing the web trying to understand what
other people think about js on or off... ;-)

I usually check client-side for all of this stuff:
!@#$%^&*()+=[]\\\';,/{}|\":<>?~`.- _£

If it's client-side that means that I can make my own page up, that's
client side too, and circumvent any protections that that you put in
place in your JavaScript.

and then, if everything is fine, I send the data to php and I do just:
$_something = htmlentities($_POST['something']);

and then it's ready to be stored on the db.

Wasn't it enough?

Well, yes and no. Ever think of checking the size of the field for
starter? What would happen if a hacker dumped a terabyte or so into that
zipcode field?

Anyway It's useless to have a double check (client-side and server-
side), so, following your ideas I should do just a server side check
but it isn't as cool as AJAX...

Or maybe I could;
CLIENT-SIDE: check if the fields are filled up correctly (so who has
js on can find it usefull) and
SERVER-SIDE: check again all the fields and, above all, look for some
characters for security reasons.

Yes, proper procedure. You still need a FORM element.

 

[^AndreA^]

great answers, I understood a lot of things...

My topic has been wholly satisfied!!!

cheers,
Andrea

 

[Travis Newbury]

And my point is there is and|or should be a certain level of competeny
  in web design. Sure you can find an autobody shop that employ duct
tape and spray-paint repairs, but doesn't make them competent, and I
certainly you not advocate the methodology.

One man's "competent" is another man's fool. Someone you may see as an
expert, I might see as an amateur. It completely depends on what your
viewpoint of an expert is. The web is way to big to have rules on how
we present content to the visitor.

Yes, have syntax rules for HTML. Have syntax rules for CSS. But
don't have rules about how someone might put the two together. I
think people (self included) get so focused on the leaf that they
completely miss the forest.

 

[Sherman Pendley]

With javascript I usually check if the fields are filled up correctly
and then I let javascript send them to the server, so I don't use the
form tag becuase I don't need it.

Is this method wrong?

Yes. Your script should only stop the form submission if there's
something wrong with the input. Keep in mind that some users will
disable JS, so your server-side script should be prepared to handle a
plain form submission that hasn't been "approved" by the JS.

Are there any downside I don't know?

Not everyone allows JavaScript, of course. And you *will* get input
from hacked pages and/or bots - count on it. "Never trust the client"
should be the mantra of *every* network programmer. So, checking input
in the client is a great way to add a convenience for users who allow
it - but then check the input again, on the server, in case the client
can't or won't do the job.

sherm--

 

[^AndreA^]

Yes. Your script should only stop the form submission if there's
something wrong with the input. Keep in mind that some users will
disable JS, so your server-side script should be prepared to handle a
plain form submission that hasn't been "approved" by the JS.


Not everyone allows JavaScript, of course. And you *will* get input
from hacked pages and/or bots - count on it. "Never trust the client"
should be the mantra of *every* network programmer. So, checking input
in the client is a great way to add a convenience for users who allow
it - but then check the input again, on the server, in case the client
can't or won't do the job.

sherm--

Sherman how can I control the form with javascript?

I mean, I write this:

<form name="input" action="plain_html_form.php" method="post" >
Username:
<input type="text" name="user"> <br />
Email:
<input type="text" name="email"> <br />

<input type="submit" value="Submit"> <br />
</form>

and then I tie a js event to the submit button.

So, when the user presses the button the js function starts, but also
the data is sent to the server... because pressing the button you
active two things simultaneously.

I'm sure there is a workaround...

Basically the question is:
how can I tie a js function to the form without breaking it?
how can I prevent the form to send data if js "says" there is
something wrong?

Actually were two questions, but they mean the same thing... ;-)

Andrea

 

[Tim Streater]

Sherman how can I control the form with javascript?

I mean, I write this:

<form name="input" action="plain_html_form.php" method="post" >
Username:
<input type="text" name="user"> <br />
Email:
<input type="text" name="email"> <br />

<input type="submit" value="Submit"> <br />
</form>

and then I tie a js event to the submit button.

So, when the user presses the button the js function starts, but also
the data is sent to the server... because pressing the button you
active two things simultaneously.

I'm sure there is a workaround...

Basically the question is:
how can I tie a js function to the form without breaking it?
how can I prevent the form to send data if js "says" there is
something wrong?

Actually were two questions, but they mean the same thing... ;-)

Andrea

Don't use a submit button, use an ordinary one. Do your validation, and
if all is OK do the submit from within js.