SELECT + GROUP (aka NEST) plus other ideas

I originally sent this message about two weeks ago to 
scotti@microsoft.com in response to his message "Design Issues for HTML 
Forms" and the referenced web page (I don't recall the URL). Anyway, 
Scott never responded so I thought I'd expose it to a larger audience. I 
suggested a <GROUP> tag akin to <NEST>. I also made some other 
suggestions which are also included below.

---------------------

You [scotti] note:
>There is no provision for checking values as they are entered into form 
>fields.

The standard solution to this is to use <SELECT> which is conventionally 
presented as a popup menu or scrolling list, but unfortunately these are 
poor ways to select from large sets of options. Allowing specification of 
hierarchical groups in the selection would make things better. This is 
discussed below. A second alternative is to create <INPUT TYPE=SET ID=x 
VALUES="...."> that would create a text entry box with a restricted set 
of values. Since most browsers treat TYPE=unknown as TYPE=TEXT, this 
would generally be backward compatible. There may be problems with the 
maximum length of attributes (I don't know if there is a limit).

Here's a simple way to specify hierarchical selections (in a way that 
preserves backward compatibility):
    <SELECT>
    <GROUP NAME=name_one>
    <OPTION>one_a
    <OPTION>one_b
    </GROUP>
    <GROUP NAME=name_two>
    <OPTION>two_a
    <OPTION>two_b
    </GROUP>
    <OPTION>three
    </SELECT>
If the term GROUP is too generic, then <SELECTGROUP> could be used 
instead.

In a traditional hierarchical menu version of this, we would see:
    group_one >> one_a
                 one_b
    group_two >> two_a
                 two_b
    three
Note that option three is in the main list directly because it's not in a 
<GROUP>. A browser that didn't understand option groups would simply 
display a regular non-grouped list or menu. If these items were displayed 
in a scrolling list, we might see:
    group_one
      one_a
      one_b
    group_two
      two_a
      two_b
    three
perhaps with little triangles to expand and collapse group items or 
whatever. Multi level hierarchies could be created by nesting <GROUP>s.

    <SELECT>
    <GROUP NAME=name_one>
    <OPTION>one_a
    <GROUP NAME=one_b>
    <OPTION>one_b_1
    <OPTION>one_b_2
    </GROUP>
    <GROUP NAME=name_two>
    <OPTION>two_a
    <OPTION>two_b
    </GROUP>
    <OPTION>three
    </SELECT>
would be:
    group_one >> one_a
                 one_b >> one_b_1
                          one_b_2
    group_two >> two_a
                 two_b
    three

One variation that would be useful:
    <GROUP NAME=group_name>
    <GROUP NAME=group_name VALUE=chosen_name>
The difference between these is that the latter would allow the group 
item itself to be selected (with the value chosen_name); the former would 
not.

>From:	walter@natural-innovations.com (Walter Ian Kaye)
>Hmm. You know what I'd rather have? Dynamic lists.

Of course the UA could choose to present a selection with groups as a 
dynamic list also.

---------------------
Here are the other ideas I sent earlier.
---------------------
    <LABEL for=radioMale accessKey=M><SPAN 
class=access>M</SPAN>ale</LABEL>
    <INPUT type=id=radioMale value="Male">

I assume you meant 
    <LABEL for=radioMale accessKey=M><SPAN 
class=access>M</SPAN>ale</LABEL>
    <INPUT type=radio id=radioMale value="Male">
or I really don't understand this.

The markup that you've used for M in this example is not tied to the 
access key in any way. (You could mark up an X but make the access key an 
M.) You can't stop people from being stupid. :-)

But my objection is that this would result in browsers marking the M even 
if they don't support access keys or access keys are disabled (some 
systems don't have keyboards after all). I would suggest leaving the 
markup to the browser, perhaps something like:
    <ACCESSKEY id=radioMale>M</ACCESSKEY>
or
    <ACCESSKEY id=radioMale key=M></ACCESSKEY>
in a case where the letter does not appear in plain text. The user could 
then specify the style of <ACCESSKEY> in a <STYLE> element which could be 
intelligently ignored by a browser that doesn't handle access keys. I 
realize that you want to allow access keys to be attached to different 
kinds of elements. Would requiring the id to be unique among all element 
kinds be unreasonably restrictive?

-- You note that the access key is case insensitive but don't specify 
that it must be limited to A-Z. Would accessKey="&aumlaut;" allowed? How 
about accessKey=1?

---------------------
I think <FIELDSET> should have an ID attribute. All <FIELDSET>s with the 
same id are a single set. This would allow for example:

     City:                State:
     ( ) Springfield      ( ) Massachusetts
     ( ) Kingston         ( ) New York
     etc.                 etc.

>The rendering for a field set is left up to the browser. The recommended 
>rendering is to place
>a box around the group and transpose the caption over the upper-left or 
>lower-left portion of
>the box depending upon the align attribute value.

You might also add that a browser should render groups (field sets) only 
if it supports set-based selection of items and that it should render the 
active group differently than other groups. It should also be acceptable 
for a browser that does not support access keys to only render a group 
distinctively when it is active.

Additionally, you do not mention that there must be a way to switch from 
tabbing between groups to tabbing within a group. You should note that 
the tabindexes of elements in the group will be used for tabbing within 
the group if grouping is activated and for global tab order if grouping 
is not active.


    --- Bruce Leban
    Akimbo Systems
    http://www.akimbo.com/globetrotter
    Publish on the web without learning HTML! (Really.)

Received on Saturday, 8 March 1997 15:13:27 UTC