browser/ecmascript behavior when form controls lack enclosing form tag?

Discussion in 'Javascript' started by jmp, Jun 7, 2006.

  1. jmp

    jmp Guest

    (I hope this isn't considered too far off-topic.)

    I work as a developer on a browser product found on handheld devices,
    and I'm trying to specify behavior for the browser to make it "as
    compatible as possible" with reference browsers (IE, Firefox, Opera,
    NS, etc??) when presented with HTML content containing form controls
    (input, textarea, select/option) in the absence of enclosing form
    element tags.

    Obviously in the absence of scripting, a form control without an
    enclosing form has no utility since there is no action associated with
    the control. But with ecmascript-mp now supported in the browser of
    course everything changes. Since the bulk of my experience up until
    very recently has been "script-agnostic" I am scrambling to figure out
    what things a content author might want to do with form controls that
    could work without the control being in a form block.

    Please let's not get into why I am trying to support such a construct,
    I'm sure those of you who have worked in a production environment are
    familiar with examples of ill-considered and poorly-specified
    requirements. Suffice it to say that some customer expects content
    with this characteristic to work on the handheld browser.

    Does anyone have ideas about what behavior should be supported (for
    form controls in the absence of enclosing form tags) for maximum
    compatibility with existing browsers and existing content?

    Does anyone know of commercial products (web-authoring tools,
    server-side HTML generating tools, etc??) that might now or in previous
    versions have produced HTML containing form controls without enclosing
    form tags?

    Again, I hope this isn't considered too far off-topic, if you feel it
    is please suggest a better forum - -

    Thanks in advance
    J
    jmp, Jun 7, 2006
    #1
    1. Advertising

  2. jmp wrote:
    <snip>
    > Obviously in the absence of scripting, a form control without
    > an enclosing form has no utility since there is no action
    > associated with the control.


    The only implication of that is that such controls would be best
    created/inserted with scripts, so they were not there whenever they were
    useless.

    > But with ecmascript-mp now supported in the browser of
    > course everything changes. Since the bulk of my
    > experience up until very recently has been
    > "script-agnostic" I am scrambling to figure out
    > what things a content author might want to do with form
    > controls that could work without the control being in a
    > form block.


    They would be used for user input.

    > Please let's not get into why I am trying to support such
    > a construct,


    The would be no point anyway as the construct is legal in HTML and so
    must be supported.

    <snip>
    > Does anyone have ideas about what behavior should be
    > supported (for form controls in the absence of enclosing
    > form tags) for maximum compatibility with existing browsers
    > and existing content?


    All of it of course. The only thing that you cannot do with a form
    control that is not in a form is submit its contents/selections to a
    server.

    > Does anyone know of commercial products (web-authoring
    > tools, server-side HTML generating tools, etc??) that
    > might now or in previous versions have produced HTML
    > containing form controls without enclosing form tags?


    That would be anything that facilitated the writing of HTML.

    > Again, I hope this isn't considered too far off-topic,
    > if you feel it is please suggest a better forum - -


    I don't see any reason for not asking here, but if you want
    cross-browser compatibility you are going to have to implement the W3C
    Core and HTML DOMs (at minimum) so once you have given the control
    elements their required interfaces what else do you need to know?

    Richard.
    Richard Cornford, Jun 7, 2006
    #2
    1. Advertising

  3. jmp

    Dag Sunde Guest

    jmp wrote:
    > (I hope this isn't considered too far off-topic.)

    <snipped />
    >
    > Does anyone have ideas about what behavior should be supported (for
    > form controls in the absence of enclosing form tags) for maximum
    > compatibility with existing browsers and existing content?


    support for all the onXxxx() events, I suppose?

    >
    > Does anyone know of commercial products (web-authoring tools,
    > server-side HTML generating tools, etc??) that might now or in
    > previous versions have produced HTML containing form controls without
    > enclosing form tags?


    All I know of...

    It is one of the most commonly used concepts, as long as scripting
    is available.

    --
    Dag.
    Dag Sunde, Jun 7, 2006
    #3
  4. jmp

    jmp Guest

    Richard Cornford wrote:
    > jmp wrote:
    > <snip>
    > > Obviously in the absence of scripting, a form control without
    > > an enclosing form has no utility since there is no action
    > > associated with the control.

    >
    > The only implication of that is that such controls would be best
    > created/inserted with scripts, so they were not there whenever they were
    > useless.
    >


    Ok, sure. That's up to the content author anyway.

    <snip>
    > > what things a content author might want to do with form
    > > controls that could work without the control being in a
    > > form block.

    >
    > They would be used for user input.
    >


    Well, Ok but is there some way to use the user input (beyond simply
    being rendered) in the absence of script?

    <snip>
    > the construct is legal in HTML and so
    > must be supported.
    >


    sorry, I only just learned that after I made the post. This browser
    started out as requiring XHTML compliant content and has subsequently
    become more and more relaxed. However the most recent releases of it do
    not create boxes in the tree for any form control that is not a child
    of a form. Since previously we didn't have script support, customers
    didn't care.

    > <snip>
    > > Does anyone have ideas about what behavior should be
    > > supported (for form controls in the absence of enclosing
    > > form tags) for maximum compatibility with existing browsers
    > > and existing content?

    >
    > All of it of course. The only thing that you cannot do with a form
    > control that is not in a form is submit its contents/selections to a
    > server.
    >


    Well, Ok, does that mean such a form control should be somehow
    addressable by script via the document.forms property or the
    document.forms.elements property? I'm guessing not since there's no
    way to address the non-existent form, but I'll admit to being new to
    ecmascript, maybe I missed something?

    When you say "all of it" I feel a bit stupid, like I should be able to
    rattle off all of the support that is required. Ok, I'll try: must be
    properly rendered, CSS applies normally, all attributes processed,
    script event handling supported, um, um, what haven't I covered?

    Given my former complete ignorance about script and admittedly mistaken
    view that form controls without enclosing form tags had no use beyond
    rendering, is there anything you might imagine I would find
    non-intuitive about the way such form controls are used by content
    authors and handled by browsers?

    <snip>
    > Richard.


    Thanks for your help
    jmp, Jun 8, 2006
    #4
  5. jmp

    jmp Guest

    Dag Sunde wrote:
    > jmp wrote:
    > > (I hope this isn't considered too far off-topic.)

    > <snipped />
    > >
    > > Does anyone have ideas about what behavior should be supported (for
    > > form controls in the absence of enclosing form tags) for maximum
    > > compatibility with existing browsers and existing content?

    >
    > support for all the onXxxx() events, I suppose?
    >


    Ok, I'm with you there.

    > >
    > > Does anyone know of commercial products (web-authoring tools,
    > > server-side HTML generating tools, etc??) that might now or in
    > > previous versions have produced HTML containing form controls without
    > > enclosing form tags?

    >
    > All I know of...
    >
    > It is one of the most commonly used concepts, as long as scripting
    > is available.
    >


    Ok, I guess I'm just surprised to hear that - I would have assumed that
    most content authors would have used an enclosing form to gain its
    various benefits. I wonder what are the most common use cases that
    omit the enclosing form?

    > --
    > Dag.


    Thanks
    jmp, Jun 8, 2006
    #5
  6. jmp wrote:
    > Richard Cornford wrote:
    >> jmp wrote:

    <snip>
    > <snip>
    >>> what things a content author might want to do with form
    >>> controls that could work without the control being in a
    >>> form block.

    >>
    >> They would be used for user input.

    >
    > Well, Ok but is there some way to use the user input (beyond
    > simply being rendered) in the absence of script?


    No, but you are writing a scriptable browsers so it can be scripted.

    > <snip>
    >> the construct is legal in HTML and so
    >> must be supported.
    >>

    >
    > sorry, I only just learned that after I made the post. This
    > browser started out as requiring XHTML compliant content
    > and has subsequently become more and more relaxed.


    It is legal in XHTML as well.

    > However the most recent releases of it do not create boxes
    > in the tree for any form control that is not a child of a
    > form.


    Then you had a bug to fix.

    > Since previously we didn't have script support,
    > customers didn't care.


    You already pointed out that such a control could be used purely for
    display. That may not be a good plan but it is allowed, and so may
    happen.

    >> <snip>
    >>> Does anyone have ideas about what behavior should be
    >>> supported (for form controls in the absence of enclosing
    >>> form tags) for maximum compatibility with existing browsers
    >>> and existing content?

    >>
    >> All of it of course. The only thing that you cannot do with
    >> a form control that is not in a form is submit its
    >> contents/selections to a server.

    >
    > Well, Ok, does that mean such a form control should be
    > somehow addressable by script via the document.forms
    > property or the document.forms.elements property?


    Without a form that would not make sense.

    > I'm guessing not since there's no way to address the
    > non-existent form, but I'll admit to being new to
    > ecmascript, maybe I missed something?


    Such a control may be addressed with - getElementById -, -
    getElementsByName -, - getElementsByTagName -, as
    children/descendants/siblings of other elements and so on.

    > When you say "all of it" I feel a bit stupid, like I should
    > be able to rattle off all of the support that is required.


    At the very least you should be able to rattle off the interfaces
    defined in the W3C HTML DOM specification for the various form controls.

    > Ok, I'll try: must be properly rendered, CSS applies normally,
    > all attributes processed, script event handling supported, um,
    > um, what haven't I covered?


    The DOM interfaces?

    > Given my former complete ignorance about script and
    > admittedly mistaken view that form controls without
    > enclosing form tags had no use beyond rendering,
    > is there anything you might imagine I would find
    > non-intuitive about the way such form controls are used by
    > content authors and handled by browsers?


    The vast majority of people writing web content have little
    understanding of the technologies they use and many work on the basis or
    coincidence, mystical incantation because things 'worked' (by some very
    superficial definitions of 'work'). Not only should you expect what they
    do to be non-intuitive, you can expect it often not even to be rational.

    Richard.
    Richard Cornford, Jun 8, 2006
    #6
  7. jmp

    Dag Sunde Guest

    jmp wrote:
    > Dag Sunde wrote:
    >> jmp wrote:
    >>> (I hope this isn't considered too far off-topic.)

    >> <snipped />
    >>>
    >>> Does anyone have ideas about what behavior should be supported (for
    >>> form controls in the absence of enclosing form tags) for maximum
    >>> compatibility with existing browsers and existing content?

    >>
    >> support for all the onXxxx() events, I suppose?
    >>

    >
    > Ok, I'm with you there.
    >
    >>>
    >>> Does anyone know of commercial products (web-authoring tools,
    >>> server-side HTML generating tools, etc??) that might now or in
    >>> previous versions have produced HTML containing form controls
    >>> without enclosing form tags?

    >>
    >> All I know of...
    >>
    >> It is one of the most commonly used concepts, as long as scripting
    >> is available.
    >>

    >
    > Ok, I guess I'm just surprised to hear that - I would have assumed
    > that most content authors would have used an enclosing form to gain
    > its various benefits. I wonder what are the most common use cases
    > that omit the enclosing form?


    * An "in-page" finance calculator.
    * A button for show/hide the details part of a page
    * A game of "tic-tac-toe"?
    * An "Old-style" AJAX implementation, where the posting is done from
    a hidden iframe, but all the controls are on the visible page.
    * the list goes on...

    --
    Dag.
    Dag Sunde, Jun 8, 2006
    #7
    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. shruds
    Replies:
    1
    Views:
    783
    John C. Bollinger
    Jan 27, 2006
  2. André
    Replies:
    2
    Views:
    724
    André
    Jun 23, 2008
  3. libsfan01

    referencing enclosing div tag

    libsfan01, Jul 27, 2006, in forum: Javascript
    Replies:
    2
    Views:
    70
  4. -Lost
    Replies:
    2
    Views:
    99
    -Lost
    Jun 11, 2007
  5. dhtml
    Replies:
    32
    Views:
    417
    Peter Michaux
    Oct 13, 2008
Loading...

Share This Page