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

Re: SELECT structures with lots of OPTIONs

From: Dave Raggett <dsr@w3.org>
Date: Tue, 7 Oct 1997 12:28:52 -0400 ()
To: dd@w3.org
cc: w3c-wai-hc@w3.org
Message-ID: <Pine.WNT.3.95.971007114336.-175423J-100000@hazel.hpl.hp.com>
On Tue, 7 Oct 1997, Daniel Dardailler wrote:

> 
> I just read through
>    http://lists.w3.org/Archives/Public/w3c-wai-ig/1997JulSep/0031.html
> 
> In general, I like the proposal and I think it just needs some
> more detailed wording on the way axis/axes determine the
> hierarchy. 
>... 
> The way I understand it, SELECT are implemented as list boxes when
> multiple-selection is used and as drop-down menu for
> single-selection. 

A possible implementation  would be to use a tab dialog where the
tabs list the top level choices and a list box on each tabbed pane
gives you the means to make detailed selections. Note that my
proposals for nested selections and for tabbed dialogs were
both turned down by the HTML WG a long while back.

> My concern is that there's going to be push-back from the
> implementors because this requires non-trivial changes to their
> browser at a late stage. 

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.

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>

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 both backwards compatible and easy to explain. The
DTD for SELECT then looks like:

  <!ELEMENT select - - (optgroup+)>
  <!ELEMENT optgroup O O (option+)>
  <!ELEMENT option - O (#PCDATA)>

This effectively wraps legacy select's in an option group.
A name attribute o the OPTGROUP can be used to label the
group. Should it be transmitted to the server? Clearly we
can't mandate this because of deployed servers. It therefore
makes sense for all options to be unique for a given SELECT
independent of how they are grouped. This isn't a problem
since even if the option caption is the same, you can use
the value attribute to distinguish them.

p.s. this proposal is consistent with the table COLGROUP
definition.

Regards,

-- Dave Raggett <dsr@w3.org> http://www.w3.org/People/Raggett
phone: +44 122 578 2521 (office) +44 385 320 444 (gsm mobile)
World Wide Web Consortium (on assignment from HP Labs)
Received on Tuesday, 7 October 1997 12:31:00 UTC

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