Joe English was nice enough to do this and I don't think many people took the
time to
respond one way or another. So here it is again. What do people think?
It seems rather simple to implement and a rather useful tool to have. If you
want this
speak up or it may never get implemented.
Matt.
On Apr 14, 3:13pm, Joe English wrote:
> Subject: PROPOSAL: Hierarchical SELECT lists (was Re: Redoing Forms)
>
> 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.
> --Joe English
>
> joe@art.com
>
>-- End of excerpt from Joe English