Re: HTML 2.0: Review Materials Available

burchard@geom.umn.edu
Errors-To: listmaster@www0.cern.ch
Date: Thu, 9 Jun 1994 04:56:17 +0200
Errors-To: listmaster@www0.cern.ch
Message-id: <9406090148.AA03506@mobius.geom.umn.edu>
Errors-To: listmaster@www0.cern.ch
Reply-To: burchard@geom.umn.edu
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: burchard@geom.umn.edu
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: Re: HTML 2.0: Review Materials Available
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
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...''
--------------------------------------------------------------------