"Richard Cornford" <Richard@litotes.demon.co.uk> wrote in message
news:c0h5qd$8q9$1$8300dec7@news.demon.co.uk...[color=blue]
> I am interested in hearing opinions on the semantic meaning of FORM
> (elements) in HTML.
>
> I have to start of apologising because this question arose in a context
> that is not applicable to the Internet. Specifically, marking up a
> document that will contain multiple related form controls (intended
> exclusively for client-side scripting) that would never be intended to
> be submitted. I realise that that concept is a non-starter in an
> Internet context but I am primarily interested in resolving the question
> of whether containing those controls in a form element would be correct
> use from a semantic point of view, and
> comp.infosystems.
www.authoring.html seems like a good place to go to get
> informed opinions on the semantic use of HTML.
>
> The argument I have been presented with is that a form is intended to be
> submitted and so controls that are not intended for submission should
> not be contained in a form for that reason.
>
> Against that I am arguing that the meaning of "form" has nothing to do
> with submission and that a form is a reasonable container for multiple
> related form controls (I would concede that a control in isolation
> probably could not be described as a form).
>
> I am basing that position on two points. The first is the dictionary
> definition of "form". Taking the first two dictionaries that came to
> hand (Chambers and Collins respectively):-
>
> Form => A printed document, esp. one with spaces in which to insert
> facts or answers: an application form.
>
> Form => A schedule to be filled in.
> (Schedule => A form for filling in particulars or such a form filled in)
>
> - Disregarding the aspects of those definitions that are irrelevant to
> the medium, the common feature is that a form has a facility to be
> filled in; "spaces in which to insert ..." - form controls. The method
> and mechanism of transport (if any) is not part of the definition of
> "form".
>
> My second point is that if the HTML 4 specification actually intended a
> form exclusively for its mechanism, to be submitted to a server, it
> should not be possible to create a form that cannot be submitted. But it
> is possible to create a form that cannot be submitted simply by not
> including any of the types of controls that can trigger a submit (so
> only radio buttons checkboxes and select elements).
>
> If forms had a specified default method of being submitted, or required
> that they contained at least one control that could be used to submit
> them, and so the only way of rendering a form non-submittable was to
> actively break it with something like client-side scripting, then I
> would happily accept that a form element was directly intended to mean a
> container for submittable content regardless of the meaning of the word
> "form". But that is not the case.
>
> So, in terms of semantic HTML mark-up, what is the correct meaning of
> FORM?[/color]
According to the spec:
"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."
http://www.w3.org/TR/html4/interact/forms.html#h-17.2.1
Which might *suggest* that you should omit the form element if the controls
are not meant for submission, though it doesn't explicitly say that.
"Control elements such as INPUT, SELECT, BUTTON, TEXTAREA, and LABEL all
respond to certain intrinsic events. When these elements do not appear
within a form, they may be used to augment the graphical user interface of
the document."
http://www.w3.org/TR/html4/interact/scripts.html#events
That sort of repeats what was above. It hints that perhaps you shouldn't
include the form element, but doesn't come right out and say that.
In my opinion, because the spec doesn't explicitly say that you need to
leave out the form element if you want to use the intrinsic events for a
user interface, the form element should be allowed for forms that don't
submit to the server. However, if you include the form, then you must also
include the action attribute. The spec says:
"This attribute specifies a form processing agent. User agent behavior for a
value other than an HTTP URI is undefined."
But again, it does not explicitly forbid a value other than an HTTP URI.
Therefore, I think it's ok to include the form element with, say, an empty
action, and use the intrinsic events with the understanding that if you
tried to submit the form, the action would be undefined, and that if the
user agent did not support a scripting language to interpret the intrinsic
events then it might not do what you want it to.
Regards,
Peter Foti
