The semantic meaning of HTML form (elements)

[Richard Cornford]

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?

Richard.

[Mark Parnell]

On Fri, 13 Feb 2004 00:30:04 -0000, "Richard Cornford"
<Ri*****@litotes.demon.co.uk> declared in
comp.infosystems.www.authoring.html:

If forms had a specified default method of being submitted,
They do. The method="" attribute has an implied initial value of GET.
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.

The action="" attribute for the form element *is* required, though.
Surely that implies that the form is supposed to do something?

Many browsers *will* submit a form that has just one text input field in
it, though they won't if there is more than one. However AFAICT, such
behaviour is undefined in the specs.

--
Mark Parnell
http://www.clarkecomputers.com.au

[Richard Cornford]

"Mark Parnell" <we*******@clarkecomputers.com.au> wrote in message
news:q9*****************************@40tude.net...
<snip>

If forms had a specified default method of being submitted,
They do. The method="" attribute has an implied initial
value of GET.

:) That is not quite what I meant. I suppose I should have said
"mechanism for" instead of "method of".

My point is that if the intention was that FORM equalled submittable
then I would expect that an unsabmittable form should be impossible to
be validly (by DTD or specification) created. Something along the lines
of specifying that if no control capable of causing the form to be
submitted had been placed within the form then a default submit button
would be created and associated with the form.

<snip>The action="" attribute for the form element *is* required,
though. Surely that implies that the form is supposed to do
something?

<snip>

Yes, the spec is very clear that the form must know where to send the
request if it is submitted. But it doesn't require that the form can be
submitted.

So I take it that your position on FORM as semantic mark-up is that the
meaning of the word "form" has no baring.

Thanks for the opinion. It hasn't swayed me (but it might contribute to
a decision by weight of numbers in the absence of anything more
substantial).

Richard.

[Peter Foti]

"Richard Cornford" <Ri*****@litotes.demon.co.uk> wrote in message
news:c0*******************@news.demon.co.uk...

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?

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

[Richard Cornford]

"Peter Foti" <pe***@Idontwantnostinkingemailfromyou.com> wrote in
message news:10*************@corp.supernews.com...
<snip>

According to the spec:
... appear outside of a FORM element declaration
when they are used to build user interfaces. ... <snip>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. <snip>

Excellent, that is probably the part of the spec most directly pertinent
to the situation.

Unfortunately it talks of user interfaces and, taking the dictionary
definition of "form", a user interface may not be a form (so no FORM
elements for sure) but it may incorporate a form or it may be a form (in
the sense of providing related provision to be filled in).
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. ... <snip>

Strictly, the action attribute is needed to produce valid HTML, but
valid HTML is good so yes it has to be there.
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
it might not do what you want it to.

My reading of RFC 2396, specifically section 4.2 "Same-document
References":-

| A URI reference that does not contain a URI is a reference to the
| current document. In other words, an empty URI reference within a
| document is interpreted as a reference to the start of that
| document, and a reference containing only a fragment identifier
| is a reference to the identified fragment of that document.
| ...

- would suggest that an empty URI is the URI of the current document and
so would be a HTTP URI if that was how the current page had been served.

However, none of this speaks for the semantic meaning of FORM elements.
I like the idea of semantic mark-up describing its contents. Generally
it is an easy concept to understand; to say that the contents of a table
element should be restricted to material for which the meaning of table
is appropriate and not determined by what a table does (visually), and
that a low level header should not be contained in font and bold tags
which say nothing about what it is but in H5 which does.

So if the content distribution and visual presentation aspects of TABLE
(what it does) are to be considered unimportant against what "table"
actually means why should the mechanism of FORM override the meaning of
"form"?

I am perfectly willing to accept that in an Internet context a "best
practice" application of FORM will *always* be submittable, but should
that be allowed to supersede its potential as a description of its
content?

Richard.

[Jukka K. Korpela]

"Richard Cornford" <Ri*****@litotes.demon.co.uk> wrote:

I am interested in hearing opinions on the semantic meaning of FORM
(elements) in HTML.
The real history and practice is that forms were hastily souped up to
satisfy, in a primitive way, the need for simple interactivity.
That is, to let authors create simple interfaces to online services.
Before that, there was <index>, which was clearly too primitive.

The rest is mixed enhancements that don't change the big picture, and a
sad history of simplistic implementations and authors' attempts to
circumvent their limitations.

Semantics? Whatever you would like to retrofit.
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.
That became part of the practice rather soon. And HTML 4 added a few
features related to it, such as <input type="button"> that makes sense
in conjunction with client-side scripting only. Besides, if they wanted
to exclude form fields outside form elements, they could have done that
easily in the syntax. So "homeless" form fields are explicitly
permitted.
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
The practical side of the matter is that if you put form field elements
inside a form, they will be submitted along with the form if they are
"successful" (to use the odd W3C term). If you plan to prevent that
with client-side scripting, then there's a problem when authoring for
the WWW, where scripting can be off.
(I would concede that a control in
isolation probably could not be described as a form).

Of course not, but it can still be used via scripting. Calling it a
form field is a bit misleading, but describes the fact the element can
be used as an interface to a browser-based "service" too.

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html