HTML 4.0 Forms proposal

MegaZone (megazone@livingston.com)
Sun, 21 Sep 1997 22:32:09 -0700 (PDT)


Message-Id: <199709220532.WAA17192@server.livingston.com>
To: www-html@w3.org
Date: Sun, 21 Sep 1997 22:32:09 -0700 (PDT)
From: MegaZone <megazone@livingston.com>
Subject: HTML 4.0 Forms proposal

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 --
  value       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" 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>

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----