Re: Form won't validate without action/method?
On Thu, 12 Feb 2004 15:13:41 -0000, Richard Cornford
<Richard@litote s.demon.co.uk> wrote:
[snip]
[color=blue]
> Designing to take advantage of server-side fall-back is usually a good
> idea so even a form that represented a control panel for something that
> could operate entirely client-side on an appropriately supportive
> browser would be sensible. But that is taking advantage of the
> submittability of forms to achieve reliability. But if the client-side
> code has no intention of ever letting the form be submitted if it is
> capable of executing I don't see that as indicating that a form should
> not be present in the HTML.[/color]
I had considered that example, but I would still class that as a
submittable form. Though you might avoid submitting it if at all possible,
the option, for reliability's sake, is still there. This might be avoided
if there are two separate pages - one for server-side, one for client-side
- but surely a hybrid would be more likely (it's simpler).
[snip]
[color=blue]
> I am not convinced that the HTML specs are going to help much here. They
> do describe and specify how a form and its controls are expected to be
> handled by a UA in the context of being submitted, they couldn't do
> otherwise the specification must specify whatever needs to be
> standardised.
>
> The specification also describes the handling of the form controls when
> a form is submitted and only leaves two control types (<input
> type="button"> and <button type="button">) exclusively for client-side
> interaction. So to the extent that it can be argued that FORM is
> intended to be submitted and so should not used in contexts where it
> will not be submitted, it might also be argued that, for example, SELECT
> is also intended to be submitted and should not be used in contexts
> where it cannot be.
>
> But while the specification describes how a FORM will be handled when it
> is submitted, and requires an action attribute so the UA will know where
> to make the request, it does _not_ require that a FORM actually be
> submittable. That is, it does not impose a default mechanism for
> submission if the form does not contain a control (such as a submit
> button, but including others) that can trigger the submission, and it
> does not require that such a control be included within the form.
>
> The HTML 4 specification does not impose submittability upon FORM
> elements. If it did it probably could be used to override a semantic
> interpretation of FORM based on the meaning (dictionary definition) of
> the word. As it doesn't I still don't see any reason for considering a
> FORM as necessarily other than a container for (multiple, related)
> "spaces in which to insert facts or answers".[/color]
I can appreciate that in a modern context, form elements could be used
purely as containers, but most of the time, it is unnecessary. If there
were a significant number of controls that needed to be accessed, I would
concede to using a container to make referencing them simpler, and it
would be illogical for me to reject the idea of containing related
controls in form just because it wasn't submitted.
Still, you probably won't see me using a form in solutions to this group
unless the OP used one (this case is an exception as the element wasn't
required at all), or it is obvious that one should be used due to the
close relationship of the controls. Rest assured I won't advise against
them, unless there is some overriding reason to do so (again, this thread
is an example).
Once again, I fall to someone else's opinions, but I do enjoy these little
chats. :)
Mike
--
Michael Winter
M.Winter@blueyo nder.co.invalid (replace ".invalid" with ".uk" to reply)
On Thu, 12 Feb 2004 15:13:41 -0000, Richard Cornford
<Richard@litote s.demon.co.uk> wrote:
[snip]
[color=blue]
> Designing to take advantage of server-side fall-back is usually a good
> idea so even a form that represented a control panel for something that
> could operate entirely client-side on an appropriately supportive
> browser would be sensible. But that is taking advantage of the
> submittability of forms to achieve reliability. But if the client-side
> code has no intention of ever letting the form be submitted if it is
> capable of executing I don't see that as indicating that a form should
> not be present in the HTML.[/color]
I had considered that example, but I would still class that as a
submittable form. Though you might avoid submitting it if at all possible,
the option, for reliability's sake, is still there. This might be avoided
if there are two separate pages - one for server-side, one for client-side
- but surely a hybrid would be more likely (it's simpler).
[snip]
[color=blue]
> I am not convinced that the HTML specs are going to help much here. They
> do describe and specify how a form and its controls are expected to be
> handled by a UA in the context of being submitted, they couldn't do
> otherwise the specification must specify whatever needs to be
> standardised.
>
> The specification also describes the handling of the form controls when
> a form is submitted and only leaves two control types (<input
> type="button"> and <button type="button">) exclusively for client-side
> interaction. So to the extent that it can be argued that FORM is
> intended to be submitted and so should not used in contexts where it
> will not be submitted, it might also be argued that, for example, SELECT
> is also intended to be submitted and should not be used in contexts
> where it cannot be.
>
> But while the specification describes how a FORM will be handled when it
> is submitted, and requires an action attribute so the UA will know where
> to make the request, it does _not_ require that a FORM actually be
> submittable. That is, it does not impose a default mechanism for
> submission if the form does not contain a control (such as a submit
> button, but including others) that can trigger the submission, and it
> does not require that such a control be included within the form.
>
> The HTML 4 specification does not impose submittability upon FORM
> elements. If it did it probably could be used to override a semantic
> interpretation of FORM based on the meaning (dictionary definition) of
> the word. As it doesn't I still don't see any reason for considering a
> FORM as necessarily other than a container for (multiple, related)
> "spaces in which to insert facts or answers".[/color]
I can appreciate that in a modern context, form elements could be used
purely as containers, but most of the time, it is unnecessary. If there
were a significant number of controls that needed to be accessed, I would
concede to using a container to make referencing them simpler, and it
would be illogical for me to reject the idea of containing related
controls in form just because it wasn't submitted.
Still, you probably won't see me using a form in solutions to this group
unless the OP used one (this case is an exception as the element wasn't
required at all), or it is obvious that one should be used due to the
close relationship of the controls. Rest assured I won't advise against
them, unless there is some overriding reason to do so (again, this thread
is an example).
Once again, I fall to someone else's opinions, but I do enjoy these little
chats. :)
Mike
--
Michael Winter
M.Winter@blueyo nder.co.invalid (replace ".invalid" with ".uk" to reply)
Comment