W3C home > Mailing lists > Public > w3c-wai-hc@w3.org > October to December 1997

Re: SELECT structures with lots of OPTIONs

From: Al Gilman <asgilman@access.digex.net>
Date: Wed, 8 Oct 1997 08:30:56 -0400 (EDT)
Message-Id: <199710081230.IAA24517@access5.digex.net>
To: w3c-wai-hc@w3.org (HC team)
to follow up on what Dave Raggett said:
> 
> A compromise is to get the HTML-WG to agree to something like:
> 
> <form>
>   <p>Nested selections
>   <select name=pizza>
>     <optgroup name=size>
>       <option>medium
[snip]

Can someone compare/contrast for me the structural semantics
implied by this OPTGROUP element as compared with UL?

It seems that as we have recognized NAME to be a local variant
of ID in A contexts, that we could recognize OPTION to be
a local variant of LI in SELECT contexts.  

Over the long haul, it would seem that one would want to be
able to wrap OPTION atoms in the same sort of structures
as LI.  All of them.  Punctuated by LH or treed out by
putting an xL inside a LI.  

If this is where we want to go in the end, let's not be
introducing more peculiar terms into the language when the
composition of the right generic constructs does the whole
job.

-- Al

PS: The case where the OPTION atoms are not all unique but
require the setting of companion parameters to discriminate
all the selectable cases is a case of a hierarchy of 
SELECT structures.  Each level of sub-SELECT entered 
identifies one parameter in the FORM and successive levels
add parameter value nominations to the stack.  Nothing is
committed unless the user makes it to the leaves of the 
tree and designates a full vertical thread.  This is
your basic pullright rule, no?
Received on Wednesday, 8 October 1997 08:31:18 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:56:11 UTC