Re: FORM element requires ACTION attribute: problems with compatibility

Mike Meyer (mwm@contessa.phone.net)
Sat, 16 Aug 1997 16:40:57 PST


In-Reply-To: <3.0.3.32.19970816155417.006efadc@emf.net>
From: mwm@contessa.phone.net (Mike Meyer)
To: www-html@w3.org
Date: Sat, 16 Aug 1997 16:40:57 PST
Message-ID: <19970816.7829B00.F59B@contessa.phone.net>
Subject: Re: FORM element requires ACTION attribute: problems with   compatibility

> From: "E. Stephen Mack" <estephen@emf.net>

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

FORM required ACTION in one of 3.2 the drafts. That breaks various
things, and it was changed back.

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

This is bad, for the same reasons it was bad in 3.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:

In HTML 2.0 and 3.2, the default for ACTION is the base URL of the
object. This is a GOOD thing, and should stay that way in HTML 4.0.

Doing it this way means authors of dynamic objects can create a single
object that spits out the form and handles the results, and it can be
moved/renamed at will without any internal changes. I.e.:

	.
	.
	.
	defaultpage = """... <FORM> ... """
	class MyForm(form.Form):
		def noquery(self): print defaultpage
		.
		.
		.

The resulting HTML is valid, and doesn't care what the URL for the
script is. If HTML 4.0 requires an ACTION on the form, then I either
have to 1) stick with HTML 3.2 (bad); 2) have scripts that produce
invalid HTML (bad); or 3) have scripts that know their name (bad).

This trick is particularly usefull when you're writing objects that
are going to get subclassed, so the FORM will appear in pages at a
number of different URLs.

Ok, every API for server-side dynamic pages lets you get the URL, but
that just makes life complicated for the author. Why do that when UAs
that want to support HTML 2.0 or 3.2 have to provide this capability
anyway? Is there some reason we want this practice to go away?

> 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.)

No, it isn't meaningless. The DEFAULT value for ACTION from HTML 2.0
(and presumably 3.2) works fine, and is usefull.

> Now, I'm not defending the current practice.  I agree that in
> principle all FORM elements should have ACTIONs, but this will

I disagree in principle, unless you can provide a fourth alternative
to the above that is cleaner than using the SCRIPT_NAME CGI variable
(or equivalent) to produce URL-independent code.

> 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.

I'd much rather they just carried forth the practice of not requiring
an ACTION on a FORM.  There are perfectly good uses for this that have
nothing to do with client-side scripting.

	<mike