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

[jmp]

(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

 

[Richard Cornford]

jmp wrote:

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.

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.

 

[Dag Sunde]

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

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.

 

[jmp]

jmp wrote:


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.

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?

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.

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?

Richard.

Thanks for your help

 

[jmp]

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

Ok, I'm with you there.

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?

Thanks

 

[Richard Cornford]

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.

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.

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.

 

[Dag Sunde]

Ok, I'm with you there.


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