Form controls not in any form

Discussion in 'HTML' started by Tim Streater, Nov 18, 2011.

  1. Tim Streater

    Tim Streater Guest

    I see various sites that use <button>s with attached onclick events to
    perform some action if the button is clicked. But these particular sites
    don't have these buttons as form controls - they are not submitting a
    form and want a button so they use it. This seems to work, but is it
    defined behaviour? Is it reliable cross-browser?

    All these buttons were like this:

    <button id='abc'>sometext</button>

    but with no <form> anywhere. I tried using a cut-down version of the
    page for some testing and was bitten by being too good and putting a
    <form> around the buttons without remembering what the default type of a
    button is in a form.

    --
    Tim

    "That excessive bail ought not to be required, nor excessive fines imposed,
    nor cruel and unusual punishments inflicted" -- Bill of Rights 1689
     
    Tim Streater, Nov 18, 2011
    #1
    1. Advertising

  2. On Fri, 18 Nov 2011 21:57:44 +0000, Tim Streater wrote:

    > I see various sites that use <button>s with attached onclick events to
    > perform some action if the button is clicked. But these particular sites
    > don't have these buttons as form controls - they are not submitting a
    > form and want a button so they use it. This seems to work, but is it
    > defined behaviour? Is it reliable cross-browser?


    I don't think any user input elements have had to be wrapped in a form
    since at least HTML 4.01.

    It should be reliable if you use a valid doctype that supports the
    functionality. Unless someone is using a browser that doesn't support
    that doctype of course.

    Ch 17 (Forms) of the 4.01 specification includes the paragraph:

    The elements used to create controls generally appear inside a FORM
    element, but may also appear outside of a FORM element declaration when
    they are used to build user interfaces. This is discussed in the section
    on intrinsic events. Note that controls outside a form cannot be
    successful controls.

    To clarify that last sentence, from elsewhere in the same chapter:

    A successful control is "valid" for submission. Every successful control
    has its control name paired with its current value as part of the
    submitted form data set. A successful control must be defined within a
    FORM element and must have a control name.

    Rgds

    Denis McMahon

    Rgds

    Denis McMahon
     
    Denis McMahon, Nov 18, 2011
    #2
    1. Advertising

  3. 2011-11-19 0:53, Denis McMahon wrote:

    > I don't think any user input elements have had to be wrapped in a form
    > since at least HTML 4.01.


    Do you mean that you were too lazy to check this out, or didn't know how
    to do that?

    > It should be reliable if you use a valid doctype that supports the
    > functionality.


    You have no idea of HTML, do you?

    > Unless someone is using a browser that doesn't support
    > that doctype of course.


    That's what I thought, no clue.

    > A successful control is "valid" for submission.


    So what does it matter if it's not within a form element?

    Hint: It cannot have any functionality unless client-side scripting is
    enabled. Does this ring a bell, anywhere?

    --
    Yucca, http://www.cs.tut.fi/~jkorpela/
     
    Jukka K. Korpela, Nov 18, 2011
    #3
  4. On Sat, 19 Nov 2011 01:14:53 +0200, Jukka K. Korpela wrote:

    > 2011-11-19 0:53, Denis McMahon wrote:
    >
    >> I don't think any user input elements have had to be wrapped in a form
    >> since at least HTML 4.01.

    >
    > Do you mean that you were too lazy to check this out, or didn't know how
    > to do that?


    I mean I know that 4.01 doesn't require input, button, select, or textarea
    to be wrapped inside a form block, I'm not sure about 3.2 and 2.0, but I
    do remember that in some incarnation, html when I started using it did
    require that input elements were inside form blocks. That was back in
    about '96.

    As I've recently been bitten by discrepancies between what tidy considers
    the right doctype for 3.2 and what w3c unicorn considers the right
    doctype, I'm limiting what I say to what I know, namely that from html
    4.01 onwards, you don't need to wrap "input" type elements in a form.

    >> It should be reliable if you use a valid doctype that supports the
    >> functionality.

    >
    > You have no idea of HTML, do you?


    Yes. We're talking, as far as I am aware, about the markup here.

    >> Unless someone is using a browser that doesn't support that doctype of
    >> course.


    > That's what I thought, no clue.


    It's possible that someone somewhere out there is using a version of of
    eg netscape that is so old that it doesn't recognise eg xhtml 1.x, or
    even html 4.01.

    Such a browser might actually break on an input element type that wasn't
    wrapped in a form block, I have very vague recollections of one of the
    early netscapes doing exactly that on a few occasions when I first
    started writing html.

    >> A successful control is "valid" for submission.

    >
    > So what does it matter if it's not within a form element?
    >
    > Hint: It cannot have any functionality unless client-side scripting is
    > enabled. Does this ring a bell, anywhere?


    As far as I can see, the op is discussing positioning of various elements
    in the html, not any underlying scripting technologies.

    Rgds

    Denis McMahon
     
    Denis McMahon, Nov 19, 2011
    #4
  5. 2011-11-18 23:57, Tim Streater wrote:

    > I see various sites that use <button>s with attached onclick events to
    > perform some action if the button is clicked. But these particular sites
    > don't have these buttons as form controls - they are not submitting a
    > form and want a button so they use it. This seems to work, but is it
    > defined behaviour?


    Basically yes. You can use the onclick attribute on almost any element
    in the document body, including <button> elements of course. The only
    vagueness is that the default for <button> is type=submit, making the
    element a submit button. When there is no enclosing form, there can be
    no form submission, so apparently this means that clicking on the
    <button> element has no effect unless there's an event attribute. This
    can be expressed by saying that outside a form, <button> has type=button
    as the default.

    > Is it reliable cross-browser?


    Yes, to the extent that client-side scripting is reliable cross-browser.

    > All these buttons were like this:
    >
    > <button id='abc'>sometext</button>
    >
    > but with no <form> anywhere.


    Presumably the page has JavaScript code that assigns event handlers to
    the elements, accessing them by the id attribute value

    > I tried using a cut-down version of the
    > page for some testing and was bitten by being too good and putting a
    > <form> around the buttons without remembering what the default type of a
    > button is in a form.


    Yeah, that's nasty. I've been bitten too - even when writing code from
    scratch. It's so easy to think that <button> has type=button as the
    default. But in reality, if you want to create a "pure button" that does
    not submit the enclosing form, you need to specify the attribute
    type=button explicitly or write the onclick event handler so that it
    ends with returning the value false (which causes the default action for
    the element to be suppressed).

    --
    Yucca, http://www.cs.tut.fi/~jkorpela/
     
    Jukka K. Korpela, Nov 19, 2011
    #5
  6. Tim Streater

    Tim Streater Guest

    In article <ja7koo$m51$>,
    "Jukka K. Korpela" <> wrote:

    > 2011-11-18 23:57, Tim Streater wrote:
    >
    > > I see various sites that use <button>s with attached onclick events to
    > > perform some action if the button is clicked. But these particular sites
    > > don't have these buttons as form controls - they are not submitting a
    > > form and want a button so they use it. This seems to work, but is it
    > > defined behaviour?

    >
    > Basically yes. You can use the onclick attribute on almost any element
    > in the document body, including <button> elements of course. The only
    > vagueness is that the default for <button> is type=submit, making the
    > element a submit button. When there is no enclosing form, there can be
    > no form submission, so apparently this means that clicking on the
    > <button> element has no effect unless there's an event attribute. This
    > can be expressed by saying that outside a form, <button> has type=button
    > as the default.


    Good, thanks.

    > > Is it reliable cross-browser?

    >
    > Yes, to the extent that client-side scripting is reliable cross-browser.
    >
    > > All these buttons were like this:
    > >
    > > <button id='abc'>sometext</button>
    > >
    > > but with no <form> anywhere.

    >
    > Presumably the page has JavaScript code that assigns event handlers to
    > the elements, accessing them by the id attribute value


    Correct.

    > > I tried using a cut-down version of the
    > > page for some testing and was bitten by being too good and putting a
    > > <form> around the buttons without remembering what the default type of a
    > > button is in a form.

    >
    > Yeah, that's nasty. I've been bitten too - even when writing code from
    > scratch. It's so easy to think that <button> has type=button as the
    > default. But in reality, if you want to create a "pure button" that does
    > not submit the enclosing form, you need to specify the attribute
    > type=button explicitly or write the onclick event handler so that it
    > ends with returning the value false (which causes the default action for
    > the element to be suppressed).


    Probably safest to do it under all circumstances.

    --
    Tim

    "That excessive bail ought not to be required, nor excessive fines imposed,
    nor cruel and unusual punishments inflicted" -- Bill of Rights 1689
     
    Tim Streater, Nov 19, 2011
    #6
    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. KatB
    Replies:
    4
    Views:
    873
  2. Malik Asif Joyia
    Replies:
    2
    Views:
    1,114
    =?Utf-8?B?ZGFuaWVs?=
    Aug 12, 2005
  3. Paul
    Replies:
    4
    Views:
    583
    Laurent Bugnion
    Sep 5, 2006
  4. Nathan Sokalski
    Replies:
    4
    Views:
    1,170
    Muhammad Naveed Yaseen
    Sep 5, 2007
  5. jim
    Replies:
    4
    Views:
    1,543
    Steve C. Orr [MCSD, MVP, CSM, ASP Insider]
    Dec 20, 2007
Loading...

Share This Page