W3C home > Mailing lists > Public > public-html-comments@w3.org > October 2010

Nested OPTGROUPs in SELECTs

From: Damian <damianjwadley@gmail.com>
Date: Sat, 16 Oct 2010 21:41:46 -0700
Message-ID: <AANLkTi=jE74WvGbuYcPVVpYhWu4iWTaQmVxEYNvavc9L@mail.gmail.com>
To: public-html-comments@w3.org
Greetings. I'd like to mention something I've seen discussed for years
now as it wasn't allowed in HTML 4, and between this list and
public-html@, here seemed the best place to bring it up:

Nesting of <optgroup> elements inside <select> elements.

The spec [1] says that an optgroup contains "zero or more option
elements" but there are situations where a second or third (or more)
grouping level could be useful. The example given uses a list of
lectures for a physics class and grouped by class topics, and could be
easily modified to include a second level.

Imagine that the physics department as a whole was in charge of making
lecture videos available. The distinction between classes could be
made within the <select> itself without needing to introduce separate
form elements for each individual class (further complicating HTML and
server-side code). The optgroup/option structure might look like

<select name="c">
.. . <optgroup label="8 Physics I">
.. . . . <optgroup label="8.01 Classical Mechanics">
.. . . . . . <option value="8.01.1">Lecture 01: Powers of Ten
.. . . . . . <option value="8.01.2">Lecture 02: 1D Kinematics
.. . . . . . <option value="8.01.3">Lecture 03: Vectors
.. . . . </optgroup>
(etc)

Existing solutions/workarounds:
- CSS (eg, padding-left) on an option
- Leading whitespace (eg, a series of NBSPs)
While adequate (though cumbersome) for visual user agents, these
solutions do not show the actual structure driving appearances -
precisely what HTML should do.

Issues:
- Leaving optgroups unclosed creates ambiguity as to whether
subsequent optgroups belong in an additional level in the same group,
or should be additional groups at the same level. I would suggest that
in such a case the user agent should assume the latter for backwards
compatibility.
- As it reuses existing HTML 4 elements, current agents might see
nested optgroups and, being visual rather than semantic elements, try
to render them using current knowledge. However in the browsers I've
seen rendering is done as it should be (ie, all optgroups are at the
top level).
- Firefox 3.6/4.0b6 applies a -moz-padding-start:20px [2] to any
optgroup>option. This behavior would be sufficient as it still
provides a visual cue (albeit less than optimal, as each option would
be indented the same amount regardless of its depth in the hierarchy).
I don't know how Internet Explorer, Safari, Opera, or other browsers
behave, but I would guess they'd act along the same lines.

The modifications to the draft that I can see:
- Contexts: as a child of a select or optgroup element
- Content model: zero or more option and/or optgroup elements
- Wording changes to include optgroups ("...represents a group of
option and/or optgroup elements...", "...disable a group of
option/optgroup elements together...", etc.)
- As a clarification: the disabled attribute would therefore disable
child optgroups as well, with an ancestor's disabled=true having
precedence over a descendant's disabled=false

Apologies if this subject has come up before - I couldn't find
anything in the mailing lists.

-Damian

[1] http://www.w3.org/TR/html5/the-button-element.html#the-optgroup-element
[2] https://developer.mozilla.org/en/CSS/-moz-padding-start
Received on Sunday, 17 October 2010 09:08:45 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 1 June 2011 00:14:05 GMT