[burchard@geom.umn.edu: Re: HTML 2.0: Review Materials Available]
"Daniel W. Connolly" <connolly@hal.com>
Message-id: <9406101613.AA07793@ulua.hal.com>
To: html-ig@oclc.org
Subject: [burchard@geom.umn.edu: Re: HTML 2.0: Review Materials Available]
Date: Fri, 10 Jun 1994 11:13:01 -0500
From: "Daniel W. Connolly" <connolly@hal.com>
Content-Length: 5556
------- Forwarded Message
Date: Wed, 8 Jun 94 20:48:46 -0500
From: burchard@geom.umn.edu
Message-Id: <9406090148.AA03506@mobius.geom.umn.edu>
To: connolly@hal.com
Subject: Re: HTML 2.0: Review Materials Available
Cc: www-talk@www0.cern.ch
Reply-To: burchard@geom.umn.edu
Dan,
The description of FORMs in HTML 2.0 specification document is still
a bit dusty from its long repose on the CERN server. As you can
imagine, I'm particularly interested in seeing good descriptions of
the graphical input elements in FORMs, but there are other rough
spots as well. Here are the problems I noticed:
> FORM
[...]
> The effect of the action can be modified by including a
> method prefix, e.g. ACTION="POST http://...." . This
> prefix is used to select the HTTP method when sending the
> form's contents to an HTTP server. [[Would it be cleaner
> to use a separate attribute, e.g. METHOD ?]
This seems out of date -- the METHOD attribute has been widely
accepted for a long time. I don't think we should encourage anyone
to use the syntax shown above.
> NAME Symbolic name used when transferring the
> form's contents. This attribute is always
> needed and should uniquely identify this
> field.
The spirit is right, but this doesn't quite hold in either direction.
Existence -- "reset" and (under certain conditions) "submit" INPUTs
can anonymous. Uniqueness -- different "radio" INPUTs can be grouped
by having the same NAME.
> SRC A URL or URN specifying an image - for use
> only with TYPE=IMAGEMAP.
There is no type "imagemap", only "image". Also, this contradicts
the later claim in the description of the "submit" abd "reset" INPUT
types, that they support the SRC attribute.
> ALIGN Vertical alignment of the image - for use
> only with TYPE=IMAGEMAP.
Again, there is no type "imagemap", only "image". And if the
"submit" and "reset" INPUTs really support the SRC attribute, they
should also accept the ALIGN attribute.
> PROPSED
>
> CHECKED When present indicates that a checkbox or
> radio button is selected.
According to the DTD and current practice, CHECKED is a standard
attribute, not merely "proposed".
> TEXT 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 DTD allows both width and height can be specified, using
space-delimited numbers. Even though the TEXTAREA element is
intended to be better suited for multiline text entry, it seems
reasonable to be liberal in this regard. Current practice also
allows both width and height to be specified, although there is some
confusion about the syntax (e.g. X Mosaic 2.4 insists on comma
separation).
> The MAX attribute can be used to
> specify an upper limit to the number of
> characters that can be entered into a text
> field, e.g. MAX=72 .
Shouldn't that be MAXLENGTH?
> CHECKBOX Used for simple Boolean attributes, or for
> attributes which can take multiple values at
> the same time. The latter is represented by a
> number of checkbox fields each of which has
> the same NAME .
Multiple checkboxes with the same NAME? I haven't seen this feature
before. What would the returned VALUE be? The spec does not say.
> SUBMIT This is a button that when pressed submits
> the form. It offers authors control over the
> location of this button. You can use an image
> as a submit button by specifying a URL with
> the SRC attribute.
This description says nothing about what is done with the SRC image
other than to use it for rendering the button. If -- as I hope --
the intent here is to smooth the transition to HTML 3.0, by offering
already in HTML 2.0 an upward-compatible alternative to the IMAGE
input, then the specification needs to be MUCH more precise in order
to achieve useful standardization.
For example, it needs to be specified that the result of clicking on
the image is to send back the selected coordinates, the x-coordinate
being associated with the key NAME.x, and the y-coordinate with
NAME.y. It should be specified that the coordinates are in pixel
units, with the origin at the top left of the image. And so on.
> PROPOSED TYPES
> SCRIBBLE A field upon which you can write with a pen
> or mouse. [...]
I am happy to see the "scribble" INPUT being advocated through the
use of "proposed" status in HTML 2.0. However, the description here
is dangerously vague! There should either be a one-sentence summary
that does not pretend to go into detail, or a MUCH more precise
specification lifted from HTML 3.0.
> OBSOLETE TYPES
> IMAGE This allows you to specify an image field
> upon which you can click with a pointing
> device. The SRC and ALIGN attributes are
> exactly the same as for the IMG and IMAGE
> elements.
Please don't give me a heart attack!!! :-) The "image" INPUT is not
obsolete in HTML 2.0! I understand that it will be obsoleted in HTML
3.0, but the HTML 2.0 DTD gives it official status, as per previous
long discussions about the goals and scope of HTML 2.0.
On the other hand, what is the IMAGE element? I can find no mention
of it anywhere in the DTD.
- --------------------------------------------------------------------
Paul Burchard <burchard@geom.umn.edu>
``I'm still learning how to count backwards from infinity...''
- --------------------------------------------------------------------
------- End of Forwarded Message