FORM element requires ACTION attribute: problems with compatibility

E. Stephen Mack (
Sat, 16 Aug 1997 15:54:17 -0700

Message-Id: <>
Date: Sat, 16 Aug 1997 15:54:17 -0700
From: "E. Stephen Mack" <>
Subject: FORM element requires ACTION attribute: problems with   compatibility

In HTML 3.2, the FORM element did not require the use of the ACTION
attribute. [1]

The draft for HTML 4.0 does require the use of the ACTION attribute
with FORM. [2]

The motivation for the change is that every form should have a form
handler.  In HTML 3.2, the ACTION attribute was not required, because
the form handler could have been script-based (i.e., JavaScript or
VBScript).  For example:

<!-- more controls here -->
<INPUT TYPE="SUBMIT" VALUE="Foo" ONCLICK="FormHandler(this.value)">

Now, HTML 4.0 allows arbitrary form control elements to appear outside
of the FORM element, since they can be handled by event attributes.
For example:

<INPUT TYPE="BUTTON" VALUE="Foo" ONCLICK="ButtonHandler(this.value)">

However, there are implementation-based problems with this approach,
so that it does not degrade gracefully.  Navigator 3.x and 4.x do not
display an INPUT element at all unless it is nested within a FORM element.
Thus, authors wanting to construct a compatible document will want to
put <FORM> and </FORM> tags around their buttons and other form controls.

Unfortunately, HTML 4.0 requires an ACTION attribute, which may be
undesirable in this case.  Web authors may try to abuse the ACTION
requirement with some kind of fake dev/null form handler, or most
likely will just leave off the ACTION attribute and create invalid documents.

There are a large number of legacy documents that use <FORM> without
an ACTION attribute.

If there's no SUBMIT button, it's meaningless to require an ACTION
attribute.  (Of course, it's equally meaningless to put the
<FORM> and </FORM> tags with no action, but that's what is currently
required by existing versions of Navigator in widespread use.)

                           * * *

Now, I'm not defending the current practice.  I agree that in
principle all FORM elements should have ACTIONs, but this will
make existing documents invalid.  HTML 3.2 does not allow BUTTON
as a valid value for the INPUT element's TYPE attribute, so
many HTML 3.2 authors will want to switch to HTML 4.0 to make
their buttons legal -- only to find that they now need to specify
a FORM handler.

                           * * *

One approach could be to use METHOD="GET" and use the ACTION attribute
to point to a URL with an alternate document that doesn't use scripting.
(An author would have to use a SUBMIT type and not a BUTTON type for
their INPUT element, however, in order to have the browser switch to the
alternate document.)

For example:
<FORM METHOD="GET" ACTION="noscripting.html">
  <INPUT TYPE="SUBMIT" VALUE="Foo" ONCLICK="ButtonHandler()">

...where the noscripting.html file could present a document that does
not use any script-handled elements.

(Of course, a CGI-based form handler is preferable since it works
with both script-enabled and non-script-enabled user agents, but
many Web authors cannot create their own custom form handlers,
either due to security restrictions or lack of programming knowledge.)

Since the above approach is both valid HTML 3.2 and HTML 4.0, and 
presents alternative content for older browsers as well as degrades
gracefully, perhaps the draft could discuss and recommend this approach.

                          * * *

While I'm thinking about <INPUT TYPE="BUTTON"> and event handlers:

In general, I think the BUTTON type is quite dependent on a visual
user agent, and does not degrade gracefully.  (Earlier discussions
here made the same points about HTML 4.0's new BUTTON element as

This all ties into a related problem, which is that there is no way
to hide an HTML element with an event attribute from a non-script-enabled
user agent.  I can use the NOSCRIPT element to present an alternative
to a script, or I can use a SCRIPT element and manually write the HTML
element with an action attribute to the document, but there's no way to

  <INPUT TYPE="BUTTON" VALUE="Foo" ONCLICK="ButtonHandler()">
  <P>Since your browser is not script-enabled, please use the
  <A href="nobutton.html">alternative document</A>.

...unless I manually construct:

<SCRIPT TYPE="text/javascript" LANGUAGE="JavaScript">
  document.write ('<INPUT TYPE="BUTTON" VALUE="Click Me"
  // -->
  <P>Since your browser is not script-enabled, please use the
  <A href="nobutton.html">alternative document</A>.

But having to constuct elements with event handlers manually
undermines the point of the event attributes in the first
place.  In general, it's hard for a Web author to construct
a scripting-enhanced document that uses event attributes but
still degrades gracefully.

I'm open to suggestions.

                          * * *

In a way, this problem parallels the anchor element issues.
Some scripts use the anchor element to point to HREF attributes
that are not actually URLs but instead script excerpts (e.g.,
<A HREF="history.back()">Go back</A>).

It should be easier to specify both script and non-script versions for
constructions like this.  But good techniques for doing so
will require some thinking, so that the solution works both with
legacy user agents and is a valid HTML approach.

E. Stephen Mack <>