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

Re: SELECT structures with lots of OPTIONs (fwd)

From: MegaZone <megazone@livingston.com>
Date: Sun, 12 Oct 1997 02:09:31 -0700 (PDT)
Message-Id: <199710120909.CAA17823@server.livingston.com>
To: w3c-wai-hc@w3.org
Sorry for the delay, I've been at InterOp...

Once upon a time Dave Raggett shaped the electrons to say...
>It is very clear that any changes involving visual user interfaces
>won't be done until the next round of browsers (5.0) It is therefore
>an extremely hard sell if we insist on this in the 4.0 spec. It is
>most likely to cause the vendors to reject 4.0 as a proposed
>recommendation.

That - and for simple backwards compatibility with the existing userbase -
is why I took pains to make the proposal compatible with the 4.0 browsers.

If a graphical browser chooses to do nothing special with axis/axes on a
TABLE it shouldn't be a problem.  Nor should it be a problem if they ignore
the OPTGROUP in a SELECT.

>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
>      <option>large
>    <optgroup name=toppings>
>      <option>onions
>      <option>meat balls
>  </select>
></form>

I don't see how this is substantially different from the original proposal
for basic organization, and it does not appear to allow for the hierarchy
development.

<SELECT name="ComOS">
<OPTGROUP id="master1" axis="Product Type" value="Comm Servers">
<OPTGROUP id="master2" axis="Product Type" value="Routers">
<OPTGROUP id="group1" axes="master1" axis="Model" value="PortMaster 3">
<OPTGROUP id="group2" axes="master1" axis="Model" value="PortMaster 2">
<OPTGROUP id="group3" axes="master2" axis="Model" value="IRX">
<OPTION axes="group1" axis="ComOS">3.7.1
<OPTION axes="group1 group2" axis="ComOS">3.7
<OPTION axes="group1 group2" axis="ComOS">3.5
<OPTION axes="group3" axis="ComOS">3.7R
<OPTION axes="group3" axis="ComOS">3.5R
</SELECT>

I view the use of 'name' on OPTGROUP as misleading.  Authors will expect
that to be returned from the form because of convention, and it will not
be for all existing clients.

I'm questioning the use of 'value' for the text as in my proposal - I was
thinking 'title' might be better.  But I'm concerned that title may be
used for something else - though I don't see what personally.  Opinions?

>or including the optional end tags
>
><form>
>  <p>Nested selections
>  <select name=pizza>
>    <optgroup name=size>
>      <option>medium</option>
>      <option>large</option>
>    </optgroup>
>    <optgroup name=toppings>
>      <option>onions</option>
>      <option>meat balls</option>
>    </optgroup>
>  </select>
>
></form>

This is similar to my old 'nest' proposal and suffers the same problem - 
what do you do when a selection is viable under multiple subgroups?  It
will appear multiple times in the collapsed list on older UAs.  And what
does it mean to select it in one place but not in another?

As in my example, where the OS revision 3.7 can be applied to multiple
classes of HW.

>A name attribute o the OPTGROUP can be used to label the
>group. Should it be transmitted to the server? Clearly we

I do not believe it should be.  Primarily for compatibility.

>makes sense for all options to be unique for a given SELECT
>independent of how they are grouped. This isn't a problem

My thoughts exactly.

>since even if the option caption is the same, you can use
>the value attribute to distinguish them.

But what about when they are truly the same thing?  This can be 
accounted for programmatically in the CGI.  But having it appear multiple
times in the SELECT is undesireable.

<!ELEMENT SELECT - - (OPTGROUP*,OPTION+) -- option selector -->
<!ATTLIST SELECT
  %attrs;                          -- %coreattrs, %i18n, %events --
  name        CDATA      #IMPLIED  -- field name --
  size        NUMBER     #IMPLIED  -- rows visible --
  multiple  (multiple)   #IMPLIED  -- default is single selection --
  disabled  (disabled)   #IMPLIED  -- control is unavailable in this context --
  tabindex    NUMBER     #IMPLIED  -- position in tabbing order --
  onfocus     %Script;   #IMPLIED  -- the element got the focus --
  onblur      %Script;   #IMPLIED  -- the element lost the focus --
  onchange    %Script;   #IMPLIED  -- the element value was changed --
  %reserved;                       -- reserved for possible future use --
  >

<!ELEMENT OPTION - O (#PCDATA) -- selectable choice -->
<!ATTLIST OPTION
  %attrs;                          -- %coreattrs, %i18n, %events --
  selected  (selected)   #IMPLIED
  disabled  (disabled)   #IMPLIED  -- control is unavailable in this context --
  value       CDATA      #IMPLIED  -- defaults to element content --
  axes        IDREFS     #IMPLIED  -- list of id's for OPTGROUPs --
  axis        CDATA      #IMPLIED  -- names groups of related options --
  >

<!ELEMENT OPTGROUP - 0 EMPTY -- grouping for OPTION -->
<!ATTLIST OPTGROUP
  %attrs;                          -- %coreattrs, %i18n, %events --
  selected  (selected)   #IMPLIED
  disabled  (disabled)   #IMPLIED  -- control is unavailable in this context --
  value       CDATA      #REQUIRED -- text to display --
  axes        IDREFS     #IMPLIED  -- list of id's for OPTGROUPs --
  axis        CDATA      #IMPLIED  -- names groups of related optgroups --
  >

-MZ
--
Livingston Enterprises - Chair, Department of Interstitial Affairs
Phone: 800-458-9966 510-737-2100 FAX: 510-737-2110 megazone@livingston.com
For support requests: support@livingston.com  <http://www.livingston.com/> 
Snail mail: 4464 Willow Road, Pleasanton, CA 94588
Received on Monday, 13 October 1997 11:42:55 UTC

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