PROPOSAL: Hierarchical SELECT lists (was Re: Redoing Forms)

Joe English (joe@trystero.art.com)
Fri, 14 Apr 95 15:13:41 EDT

Matthew MacDonald <mmacdona@pcocd2.intel.com>
wrote in <9504141014.ZM13766@fiw019.fm.intel.com>:

[ Good rationale ]

So what you're really after is a way to organize
long option lists hierarchically, correct?

I would suggest this approach: instead of allowing
nested <SELECT> elements, change the content models from:

<!ELEMENT SELECT - - (OPTION+)>
<!ELEMENT OPTION - O (#PCDATA)*>

to:

<!ELEMENT SELECT - - ((OPTION | OPTGRP)+)>
<!ELEMENT OPTGRP - - (OPTHEAD, (OPTION | OPTGRP)+)>
<!ELEMENT OPTHEAD O O (#PCDATA)>
<!ELEMENT OPTION - O (#PCDATA)>

<!-- <OPTGRP> Option group -->
<!-- <OPTHEAD> Option group heading -->

where the (new) OPTGRP element delimits groups of options,
and OPTHEAD supplies a a heading or title for the subgroup.
OPTGRP elements are fully recursive.

OPTGRP and OPTHEAD have no attributes (other than the usual
ID, CLASS, and LANG for HTML+).

Possible rendering options for SELECT elements with option groups include:

* a series of cascading pull-right menus,
* a collapsible outline like the Mac System 7 directory menu,
* a two- column selection list like the Motif/Windows
directory/file browser,
* a three-column selection list like the NeXT directory browser,
* a selection list for the options with a "combobox"-type
menu for the directory hierarchy, like the Mac file selection dialog;
* others?
* a flat list with no hierarchy.

(Not all of these are appropriate for <SELECT MULTIPLE=MULTIPLE>...)

IMPACT ON EXISTING BROWSERS:

Assuming that browsers ignore the unrecognized <OPTGRP>
and <OPTHEAD> elements, they will simply render hierarchical
<SELECT> lists as flat lists with no hierarchy, since all
that's left are the (leaf) <OPTION> elements.

This is a legal display option as outlined above, so existing
browsers already correctly implement this feature :-)

EXAMPLE OF USE:

Matthew MacDonald's example would be tagged as follows:

<form action="mailto:joe@art.com">
<select name=part>
<optgrp><opthead>Ford</opthead>
<optgrp><opthead>engine</opthead>
<option>rotors</option>
<option>belts</option>
<option>fans</option>
</optgrp>

<optgrp><opthead>headlights</opthead>
<option>highbeams</option>
<option>lowbeams</option>
<option>fog</option>
</optgrp>

<!-- or using tag minimization -->

<optgrp>antennas
<option>radio
<option>t.v.
<option>cb
</optgrp>
</optgrp>

<optgrp>Chevy
<!-- ... -->
</optgrp>
</select>
</form>

NOTES:

I tested this example with NCSA Mosaic for X 2.4 to see if
it would fail to barf, and it does not appear to do the right
thing with the <OPTHEAD>s. So much for "ignore unrecognized
elements".

It also screws up on the </OPTION> end-tags, creating a blank option
wherever one appears in the source markup.

AN INTERESTING PROBLEM:

Please see my next message.

--Joe English

joe@art.com