Re: PROPOSAL FOR A MULTI-COLUMN SELECT ELEMENT WITHIN A FORM

Paul Prescod (papresco@calum.csclub.uwaterloo.ca)
Fri, 06 Sep 1996 13:33:49 -0400


Message-Id: <1.5.4.32.19960906173349.0075c76c@csclub.uwaterloo.ca>
Date: Fri, 06 Sep 1996 13:33:49 -0400
To: ianweb@smaug.java.utoronto.ca (Ian Graham),
From: Paul Prescod <papresco@calum.csclub.uwaterloo.ca>
Subject: Re: PROPOSAL FOR A MULTI-COLUMN SELECT ELEMENT WITHIN A FORM
Cc: www-html@w3.org

At 10:15 AM 9/6/96 -0400, Ian Graham wrote:
>Instead, I believe it would be best to establish an easy-to-author form 
>interface description language (perhaps as part of HTML). There is then
>no reason one  browser could not render FORM element-like content using 
>an applet or a java-based plugin module,  while another uses some other 
>mechanism to do so (e.g. another java plugin, designed for another interface, 
>or a coded-in interpreter, as is done now). 

This is an excellent idea (perhaps better than the original!), and I think
it should be incorporated. Couldn't it be done through the standard
"alternative text" mechanism for objects, the OBJECT's content? The UA would
have to know that an INPUT in an OBJECT should be treated as an alternative
and it should only query the OBJECT if the UA supports objects.

But I also think that there is a place for Java form elements that CANNOT be
represented as traditional form elements, just as there is a place for IMGs
and OBJECTs that do not have a completely isomorphic text equivalent (i.e.
here is a picture of my cat). I was going to suggest a NAME attribute on
OBJECTs, but in looking at the spec, I realize that they already have one,
and it is defined just as I would have defined it. Oops.

The only thing missing is an explicit instruction that an OBJECT that
participates in a FORM can have an alternate INPUT in its content and only
one or the other should be submitted.

 Paul Prescod