- From: MegaZone <megazone@livingston.com>
- Date: Mon, 13 Oct 1997 17:20:24 -0700 (PDT)
- To: w3c-wai-hc@w3.org
Once upon a time Jason White shaped the electrons to say... >I think there is a need to use a container to create hierarchies of SELECT >elements. This structure can not be captured if the grouping elements I disagree. Containers are flawed in cases where OPTIONs can be reached via multiple paths. They do not collapse well. The axis/axes relational system seems to work well. I haven't seen an argument against it other than the graphical browsers might not like it - and I don't consider that a reason to abandon accessibility. Version 3 - 10/13/97 Changed 'value' on OPTGROUP to 'label' for better differentiation from other uses of value in forms. Version 2 - 9/25/97 I added 'selected' and 'disabled' to OPTGROUP element. After some thought I decided that users might want to disable an entire subgroup, especially programatically. There may also be a desire to preselect one or more subgroups. Version 1 - 9/21/97 You know how you can nest lists with most windowing systems? Like in NS bookmarks when you can have an arrow on the right which has a sublist; so that you can have a hierarchical organization for pick lists. I'd like to see that for SELECT lists in HTML and I think it can be done so that it will not break current browsers. I originally proposed this just after HTML 3.2 came out, but I think I found a more flexible way to do it after looking at the HTML 4.0 specification. The original proposal is at the bottom for reference. This new proposal solves the problem of having elements appear multiple times in a list in older UAs, when you want them to be in multiple areas in a new UA. Using the idea of 'id' and 'axes' borrowed from the new table spec, you can create groupings. Hope I get the SGML right... <!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 -- label CDATA #REQUIRED -- text to display -- axes IDREFS #IMPLIED -- list of id's for OPTGROUPs -- axis CDATA #IMPLIED -- names groups of related optgroups -- > As an example: <SELECT name="ComOS"> <OPTGROUP id="master1" axis="Product Type" label="Comm Servers"> <OPTGROUP id="master2" axis="Product Type" label="Routers"> <OPTGROUP id="group1" axes="master1" axis="Model" label="PortMaster 3"> <OPTGROUP id="group2" axes="master1" axis="Model" label="PortMaster 2"> <OPTGROUP id="group3" axes="master2" axis="Model" label="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> In any older UA it would simply be: +-----+ |3.7.1| |3.7 | |3.5 | |3.7R | |3.5R | +-----+ A newer UA would be something like: +-------------+ |Comm Servers>| |Routers> | +--------------+ If a user were to them go to 'Comm Servers' it would be: +-------------+ |Comm Servers>+-------------+ |Routers> |PortMaster 3>| +-------------|PortMaster 2>| +-------------+ 'PortMaster 3' would then expand to: +-------------+ |Comm Servers>+-------------+ |Routers> |PortMaster 3>+-----+ +-------------|PortMaster 2>|3.7.1| +-------------|3.7 | |3.5 | +-----+ 'PortMaster 2' would expand to: +-------------+ |Comm Servers>+-------------+ |Routers> |PortMaster 3>| +-------------|PortMaster 2>+---+ +-------------|3.7| |3.5| +---+ Non-graphic UAs could build a hierarchy, as they can with tables: Comm Servers PortMaster 3 3.7.1 3.7 3.5 PortMaster 2 3.7 3.5 Routers IRX 3.7R 3.5R ----ORIGINAL PROPOSAL---- <!ELEMENT SELECT - - (OPTION | NEST)+> <!ATTLIST SELECT name CDATA #REQUIRED size NUMBER #IMPLIED multiple (multiple) #IMPLIED > <!ELEMENT OPTION - O (#PCDATA)*> <!ATTLIST OPTION selected (selected) #IMPLIED value CDATA #IMPLIED -- defaults to element content -- > <!ELEMENT NEST - - (OPTION | NEST)+> <!ATTLIST NEST title CDATA #REQUIRED > This would be used as follows: <SELECT NAME="testlist"> <OPTION>first item <NEST title="stuff"> <OPTION>another <OPTION>yet another <OPTION>still another <NEST title="layer"> <OPTION>third level </NEST> </NEST> <OPTION>last item </SELECT> This would be rendered as: +----------+ |first item| |stuff> | |last item | +----------+ If a user were to them go to 'stuff' it would be: +----------+ |first item| |stuff> +-------------+ |last i |another | +-------|yet another | |still another| |layer> | +-------------+ Which would then expand to: +----------+ |first item| |stuff> +-------------+ |last i |another | +-------|yet another | |still another| |layer> +-----------+ +-------|third level| +-----------+ the values would all be returned under the key 'testlist' as the NEST title is just for the display. As unknown tags are ignored, older browsers - and perhaps those without a convenient way of doing nesting (lynx?) would render it as a straight list: +-------------+ |first item | |another | |yet another | |still another| |third level | |last item | +-------------+ ----END ORIGINAL PROPOSAL----
Received on Monday, 13 October 1997 20:26:35 UTC