Re: Paul Burchard on HTML 2.0 FORMs
eric@oclc.org (Eric W. Sink)
Date: Tue, 12 Jul 94 08:08:44 EDT
Message-id: <9407121207.AA04470@hook.spyglass.com>
Reply-To: html-ig@oclc.org
Originator: html-ig@oclc.org
Sender: html-ig@oclc.org
Precedence: bulk
From: eric@oclc.org (Eric W. Sink)
To: Multiple recipients of list <html-ig@oclc.org>
Subject: Re: Paul Burchard on HTML 2.0 FORMs
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
X-Comment: HTML Implementation Group (Private)
>As far as I am aware, the only item in these documents not supported
>by X Mosaic 2.4, is the ability of the SUBMIT field to use the NAME
>attribute when it is supplied. (I could not bear to erase this
>feature from the spec myself, though. :-)
No version of Mosaic supports this feature. It is not difficult to
add, but where did the idea come from?
>The default method is GET, although for many applications,
>the POST method will be preferred. In the latter case,
This reminds me - are attributes like this to be recognized
case-sensitively ? XMosaic actually does match case, so that
a form which reads
<FORM METHOD="post")
is handled as a GET. We've found one Web site which is coded exactly
this way, and their server really is expecting a GET! So, any browser
which matches this attribute without regard to case, fails on their
server!
>the ENCTYPE attribute is a MIME type
>specifying the format of the POSTed data
>(by default <CODE>application/x-www-form-urlencoded</CODE>).
Not only is that the default ENCTYPE, it is the only one
supported by any browser I know of.
By the way, I'd love to see another attribute on the FORM
tag, called SECUREONLY:
<FORM METHOD="POST" SECUREONLY>
Basically, this tag forces the browser to refuse to send
the user-entered information in a non-secure fashion.
Since I know of no browsers implementing SHTTP or some
relevant alternative, all current browsers would implement
this attribute by simply refusing to submit the form.
This is of course not descriptive, so it should not be a part
of our spec. I just wanted to see if anyone thought it was
a dumb idea.
><DT>SIZE
><DT>MAXLENGTH
I believe the SIZE and MAXLENGTH tags are only relevant for
TYPE=TEXT.
><DD>The maximum number of characters that will be accepted as
>input. This can be greater that specified by SIZE,
>in which case the field will scroll appropriately.
>The default is unlimited.
Or, it may be limited by the platform.
><DT>TEXT
>
><DD>Single line text entry fields. Use the SIZE attribute to
>specify the visible width in characters,
>e.g. SIZE="24" for a 24 character field.
>The MAXLENGTH attribute can be used to specify an upper limit to the
>number of characters that can be entered into a text field,
>e.g. MAXLENGTH=72 . Use the <A NAME="z1"
>HREF="TEXTAREA.html">TEXTAREA</A>
>element for text fields which can accept multiple lines.
Some browsers seem to support SIZE="5,5" for a multiline
edit field. Are we intentionally deprecating this?
><DT>IMAGE
>
><DD>An image field upon which you
>can click with a pointing device, causing the form to be
>immediately submitted. The coordinates of the selected point,
>measured in pixel units from the upper left-hand corner of the
>image, are returned (along with the other contents of the form)
>in two name/value pairs. The <I>x</I>-coordinate is submitted
>under the NAME of the field with ".x" appended, and the
><I>y</I>-coordinate is submitted under the NAME of the field
>with ".y" appended. Any VALUE attribute is ignored.
>The image itself is specified by the SRC attribute, exactly
>as for the IMG element.
Trivia: some servers only seem to support this if the
n.x&n.y string is at the END of the group of name,value pairs.
Anyone know why?
We may want to mention that a FORM image map is ignored
when submitting the form through any other mechanism, like
the SUBMIT button.
><DT>SUBMIT
>
><DD>This is a button that, when pressed, submits the form.
>The VALUE attribute can be used to provide a (non-editable)
>label to be displayed on the button (the default label is
>application-specific). The NAME attribute is not
>required; a submit button will only contribute a name/value
>pair to the submitted data if it both has a NAME, and was
>the button that was pressed in order to submit the form.
As I said before, I don't know any browser which supports the
NAME/VALUE pair on a SUBMIT button.
><DT>RESET
>
><DD>This is a button that, when pressed, resets the form's
>fields to their initial values, as defined by each
>field's VALUE attribute.
This is not strictly true. In the case of a TEXTAREA, the
initial value is not stored in the VALUE attribute (nitpick,
I know).
><H3>Obsolete usage</H3>
>
><P>When you need to let users enter more than one line of text,
>you should use the <A NAME="z1"
>HREF="TEXTAREA.html">TEXTAREA</A> element, rather than an INPUT
>of type TEXT.
OOPS! I guess this answers my question above.
I can't wait till we have a real standard like this to refer to.
Currently, we get a lot of pressure to add specific features and
functionality to our Mosaic implementations. The usual argument
goes something like, "Well, XMosaic 2.4 supports this, so you
HAVE TO support it too!". As if someone assigned an RFC number to
XMosaic...
Eric W. Sink, Software Engineer -- eric@spyglass.com 217-355-6000 ext 237
All opinions expressed are mine, and may not be those of my employer.
"Only academic people put cheese in their pocket."
-SW, 24 May 1994