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

Greg A. Smith (gasmith@advtech.uswest.com)
Mon, 09 Sep 1996 16:45:16 -0600


Message-ID: <32349DFC.847@advtech.uswest.com>
Date: Mon, 09 Sep 1996 16:45:16 -0600
From: "Greg A. Smith" <gasmith@advtech.uswest.com>
To: Ian Graham <ianweb@smaug.java.utoronto.ca>
CC: Paul Prescod <papresco@calum.csclub.uwaterloo.ca>, www-html@w3.org
Subject: Re: PROPOSAL FOR A MULTI-COLUMN SELECT ELEMENT WITHIN A FORM

Ian Graham wrote:
> 
> A question, and two thoughts?
> 
> If PRE formatting (fixed-width, preservation of whitespace, etc) passed
> through to FORM input element text content (INPUT and SELECT), would this
> provide the required MSELECT funcionality?  IF so, then this might be
> an easier implementation path.
> 
Although it would not be as flexible or as nicely rendered on the screen 
as the MSELECT, it would provide the needed functionality.  Those of us
who were working on Web-based relational database apps on UNIX systems 
were fully expecting this to work the same way on Windows and were
sorely disappointed when it didn't.  Netscape answered our complaints
then by saying, 'just wait for tables and frames', as if that would
solve the problem.  It didn't by a long shot.

> I do like the idea of using Java applets to render complex FORM-like
> interfaces, but note the major problems this approach would present for
> users with non-graphical browsers. This may be a small minority of users
> but not one I wish not to ignore.
> 
The MSELECT as I have defined it would work equally well on text-only
systems.  In fact it would appear pretty much as it does in my proposal.
I have seen multi-column scrollable pick lists like this implemented
on many text-only devices.

> 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 would be a bit like the
> so-called "HTML Layout Controls" that Microsoft implements using ActiveX,
> but more flexible in terms of the interface.
> 
While I'm not against these ideas for add-ons using plug-ins, applets, 
and Form Description Languages (FDLs?), the need for the MSELECT's 
functionality is sufficient that it should be added to the core language.  
Database application developers should be able to create front-ends with 
the confidence that any standard-compliant browser can run them.

====================================================================
Gregory A. Smith
303-541-6006
gasmith@advtech.uswest.com