- From: Damian <damianjwadley@gmail.com>
- Date: Sat, 16 Oct 2010 21:41:46 -0700
- 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 UTC