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

Arnoud Galactus Engelfriet wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> 
> In article <32271BDE.52FD@advtech.uswest.com>,
> "Greg A. Smith" <gasmith@advtech.uswest.com> wrote:
> > On some UNIX systems, developers have been able to kludge multi-
> > column SELECTs by specifying PRE tags for the text displayed for
> > the OPTIONs.  If the OPTION text has been pre-spaced so that it
> > aligns in columns, the PRE tag should preserve this spacing on
> > the user's display -- provided the user is using the specified
> > platform.
> 
> Yikes. You're relying pretty much on how your browser renders the
> SELECT element.
> 
I can't rely on it, which is why I am making this proposal.

> > For this reason, I propose that the following FORM element be added
> > to the HTML 3.2 specification.
> 
> Sorry, no chance of that:
> 
> The 13 Aug DTD says:
> 
>         This is subject to change, pending final approval by the W3C
>         member companies. Changes are limited to bug fixes at this time.
> 
> Perhaps Cougar?
It is never too late to change if one is willing to change, if the deadline
has passed for 3.2, then I would be happy to see this adopted by 3.3 or
whatever follows 3.2.  The important thing is to get adopted ASAP.

> 
> > MSELECT will be used as a FORM element like SELECT except that
> > it will always be displayed as a list -- never as a pop-down menu.
> 
> So what exactly is it supposed to do? My browser doesn't display
> SELECT as a pop-down menu, even when the SIZE is set to one.
> 
SELECT may be displayed as a pop-down (on some browsers, anyway), 
MSELECT would be restricted to a list.

> > MSELECT uses OPTION tags for each of its selectable rows just as
> > SELECT does, but it adds the following optional tags.
> >
> > TITLE  specifies text to use as the title of the list box.
> >        It uses an optional ALIGN attribute with the values: LEFT, RIGHT,
> >        or CENTER.
> 
> This sounds a lot more like CAPTION. TITLE is already taken in the
> head of the document.
Just as the browser can distinguish an LI in UL from an LI  an OL it 
should be able to distinguish a TITLE in an MSELECT from a TITLE in a 
HEAD, but the name TITLE is not that important.  I considered using 
CAPTION as well. Although I think the word TITLE is more descriptive 
of its function, I would be willing to bend on this.

> 
> > The OPTION tag works exactly as it does for SELECT with one exception:
> > It must be followed by a set of MD tags instead of text.
> 
> Hm. You'd have to define a new element for this, then. You can't
> define OPTION differently depending on the element it is used inside.
> 
> > MD     The number of MD tags for each OPTION must be the same.
> 
> Why? Can't I just leave the last few MDs off if they're empty, like
> you can do with table rows?
Good point.  My concern was with the ease of parsing this element.  If
the rules are too complicated, the parser may become confused as to how 
many columns to display and what fields go into what columns.  I was
following the KISS philosophy here.

> 
> And how does my selected MD (which I suppose is what should happen)
> transferred to the form?
Just as with the SELECT element, the NAME=VALUE (NAME is an attribute 
for the SELECT tag, VALUE is an attribute of the selected OPTION) pair 
is added to the query string.  

> 
> Maybe I'm missing something important, but I don't see the need for
> this element. How would this differ from using a TABLE to align
> multiple checkboxes?
> 
I think a lot of people, who don't develop database applications are
missing the importance this functionality.  When a database developer
discovers that the PRE functionality is missing from browsers on Windows
platforms he starts looking for alternatives.  TABLE is the first thing
he sees, but a table is not a form element and it isn't a scrollable
widget.  The best a developer can do with a table is an unsatisfying 
kludge of a scrollable SELECT widget with frames for scrolling and radio 
buttons in one column as a way of selecting a row.

The scrollable multi-column select widget, a staple of every front-end
relational database tool from Access to Windows4GL, is missing.  That's
why you don't see more of these types of applications on the web.

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

Received on Tuesday, 3 September 1996 13:01:01 UTC