EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are
satisfied with this response, please change the state of this bug to CLOSED. If
you have additional information and would like the Editor to reconsider, please
reopen this bug. If you would like to escalate the issue to the full HTML
Working Group, please add the TrackerRequest keyword to this bug, and suggest
title and text for the Tracker Issue; or you may create a Tracker Issue
yourself, if you are able to do so. For more details, see this document:

   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale: Test case:

http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1047

This creates a DOM like

SELECT
    OPTION
        #text: 0
    OPTGROUP label="A"
        OPTION
            #text: 1
    OPTGROUP label="B"
        OPTGROUP label="C"
            OPTION
                #text: 2
    SPAN
        OPTION
            #text: 3
    SPAN
        OPTGROUP label="D"
            OPTION
                #text: 4
    OPTGROUP label="E"
        SPAN
            OPTION
                #text: 5

and then logs the textContent of all options in select.options.

IE9 logs 0 and 1, and displays

  0
  A
    1
  B
  E

Firefox 6.0a2 logs 0-2, but displays the same as IE.  Chrome 14 dev logs 0-5, and displays

  0
  A
    1
  B
  C
    2
  E

Opera 11.11 logs 0-5 and displays

  0
  A
    1
  B
    C
      2
  E

Conclusions:

* Only Opera has meaningful support for nested optgroups.  Chrome displays it the same as if you had an extra empty optgroup, and IE/Firefox ignore the contents of the nested optgroups entirely.
* In practice, the algorithm in the spec returns exactly the option elements that currently are displayed to the user in the two largest browsers.
* IE matches the spec exactly, while all other browsers have mismatches between what the .options attribute displays and what they show to the user.

Thus the current spec seems good.  It codifies IE's behavior, which matches Firefox's visual behavior and makes more sense than Chrome's behavior.  The only way I'd see we'd want to change this is if we actually allowed nested optgroups and required behavior like Opera, but those don't serialize, so it's a nonstarter.  There's no reason to change the spec plus IE to account for things that can't actually happen in text/html.

mass-moved component to LC1