what is <form> useful for?

Discussion in 'HTML' started by ^AndreA^, Jul 24, 2008.

  1. ^AndreA^

    ^AndreA^ Guest

    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
     
    ^AndreA^, Jul 24, 2008
    #1
    1. Advertising

  2. ^AndreA^ wrote:
    > 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?

    --
    Take care,

    Jonathan
    -------------------
    LITTLE WORKS STUDIO
    http://www.LittleWorksStudio.com
     
    Jonathan N. Little, Jul 25, 2008
    #2
    1. Advertising

  3. On Jul 24, 7:05 pm, "Jonathan N. Little" <> wrote:
    > And when JavaScript is disabled?


    Then it breaks and the visitor has a decision to make...
     
    Travis Newbury, Jul 25, 2008
    #3
  4. Gazing into my crystal ball I observed "^AndreA^"
    <> writing in news:1b2e5674-0c32-4743-9b8e-
    :

    > 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.
     
    Adrienne Boswell, Jul 25, 2008
    #4
  5. Travis Newbury wrote:
    > On Jul 24, 7:05 pm, "Jonathan N. Little" <> wrote:
    >> And when JavaScript is disabled?

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


    Poor choice of design implementation.

    --
    Take care,

    Jonathan
    -------------------
    LITTLE WORKS STUDIO
    http://www.LittleWorksStudio.com
     
    Jonathan N. Little, Jul 25, 2008
    #5
  6. ^AndreA^

    dorayme Guest

    In article <acdd6$4889418f$40cba7b7$>,
    "Jonathan N. Little" <> wrote:

    > Travis Newbury wrote:
    > > On Jul 24, 7:05 pm, "Jonathan N. Little" <> wrote:
    > >> And when JavaScript is disabled?

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

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

    --
    dorayme
     
    dorayme, Jul 25, 2008
    #6
  7. ^AndreA^

    Art Sackett Guest

    On Fri, 25 Jul 2008 01:13:43 +0000, Adrienne Boswell wrote:

    > 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...
     
    Art Sackett, Jul 25, 2008
    #7
  8. ^AndreA^

    viza Guest

    On Thu, 24 Jul 2008 15:38:00 -0700, ^AndreA^ wrote:

    > 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.
     
    viza, Jul 25, 2008
    #8
  9. viza wrote:
    > On Thu, 24 Jul 2008 15:38:00 -0700, ^AndreA^ wrote:
    >
    >> 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.


    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)

    ).
     
    Harlan Messinger, Jul 25, 2008
    #9
  10. ^AndreA^

    ^AndreA^ Guest

    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
     
    ^AndreA^, Jul 25, 2008
    #10
  11. ^AndreA^ wrote:
    > 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.
     
    Harlan Messinger, Jul 25, 2008
    #11
  12. On Jul 24, 11:13 pm, dorayme <> wrote:
    > 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.

    --
    Travis Newbury <http://travisnewbury.blogspot.com/> Flash Crap
    Travis Newbury <http://travisnewbury.blogspot.com/> Flash Crap
    Travis Newbury <http://travisnewbury.blogspot.com/> Flash Crap
    Travie Newbury <http://travisnewbury.blogspot.com/> Flash Crap
     
    Travis Newbury, Jul 25, 2008
    #12
  13. ^AndreA^

    Art Sackett Guest

    On Fri, 25 Jul 2008 04:53:16 -0700, ^AndreA^ wrote:

    > 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.
     
    Art Sackett, Jul 25, 2008
    #13
  14. Travis Newbury wrote:
    > On Jul 24, 11:13 pm, dorayme <> wrote:
    >> 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.


    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.


    --
    Take care,

    Jonathan
    -------------------
    LITTLE WORKS STUDIO
    http://www.LittleWorksStudio.com
     
    Jonathan N. Little, Jul 25, 2008
    #14
  15. ^AndreA^ wrote:
    > 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.

    --
    Take care,

    Jonathan
    -------------------
    LITTLE WORKS STUDIO
    http://www.LittleWorksStudio.com
     
    Jonathan N. Little, Jul 25, 2008
    #15
  16. ^AndreA^

    ^AndreA^ Guest

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

    My topic has been wholly satisfied!!!

    cheers,
    Andrea
     
    ^AndreA^, Jul 25, 2008
    #16
  17. On Jul 25, 9:03 am, "Jonathan N. Little" <> wrote:
    > 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.
    --
    Travis Newbury <http://travisnewbury.blogspot.com/> Flash Crap
    Travis Newbury <http://travisnewbury.blogspot.com/> Flash Crap
    Travis Newbury <http://travisnewbury.blogspot.com/> Flash Crap
    Travis Newbury <http://travisnewbury.blogspot.com/> Flash Crap
     
    Travis Newbury, Jul 25, 2008
    #17
  18. "^AndreA^" <> writes:

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

    --
    My blog: http://shermspace.blogspot.com
    Cocoa programming in Perl: http://camelbones.sourceforge.net
     
    Sherman Pendley, Jul 25, 2008
    #18
  19. ^AndreA^

    ^AndreA^ Guest

    On Jul 25, 2:48 pm, Sherman Pendley <> wrote:
    > "^AndreA^" <> writes:
    > > 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--
    >
    > --
    > My blog:http://shermspace.blogspot.com
    > Cocoa programming in Perl:http://camelbones.sourceforge.net


    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
     
    ^AndreA^, Jul 25, 2008
    #19
  20. ^AndreA^

    Tim Streater Guest

    In article
    <>,
    "^AndreA^" <> wrote:

    > On Jul 25, 2:48 pm, Sherman Pendley <> wrote:
    > > "^AndreA^" <> writes:
    > > > 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--
    > >
    > > --
    > > My blog:http://shermspace.blogspot.com
    > > Cocoa programming in Perl:http://camelbones.sourceforge.net

    >
    > 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.
     
    Tim Streater, Jul 25, 2008
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. ben cohen
    Replies:
    0
    Views:
    1,097
    ben cohen
    Aug 20, 2003
  2. Andreas Klemt
    Replies:
    1
    Views:
    407
    Cowboy \(Gregory A. Beamer\)
    Jan 14, 2004
  3. Brock Allen
    Replies:
    4
    Views:
    2,077
    =?Utf-8?B?dHhnaGlhNTg=?=
    Apr 17, 2005
  4. =?Utf-8?B?Sm9obg==?=

    if(blah) alert box else somethinge useful

    =?Utf-8?B?Sm9obg==?=, Jun 9, 2005, in forum: ASP .Net
    Replies:
    3
    Views:
    2,360
    =?Utf-8?B?Sm9obg==?=
    Jun 9, 2005
  5. Aoife Kavanagh
    Replies:
    0
    Views:
    328
    Aoife Kavanagh
    Nov 19, 2003
Loading...

Share This Page