Not necessarily, but I can't think of anything that I might
describe as a form, that I wouldn't implement as a submittable
form. As I pointed out, creating random examples isn't my forte.
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.
The former. For example, a DIV should partition a document
logically. It shouldn't be used just because it puts some space
above and below the element, particularly as there is nothing in
the specification that says it should do so.
This then brings us back full-circle: what does 'form' mean,
and should that meaning be the limit of its use?
The initial intent would appear to be for submission to a
server, indicated by the required status of the action attribute,
The initial intent is not necessarily relevant as initially client-side
scripting did not exist and so did not need to be considered in design
decisions. And initially the action attribute was not required. Though
the fact that it is required now may speak for current intent.
and this, from the Specification:
"Users generally 'complete' a form by modifying its controls...
before submitting the form to an agent for processing."
Based on that, forms shouldn't be used for easy reference,
but only if you mean to send data.
An interesting choice of quote; the section that I considered quoting,
pointing out that the "agent" receiving the form information could
reasonable be the client-side code. I decided not to because later
sections in the HTML spec could easily undermine that position.
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".
Richard.