[Bug 12665] This definition seems slightly wrong; if you have a tree like (assume XML-style parsing) <select><optgroup><optgroup><option>foo[...] UAs give options.length = 1, not 0. Basically the algorithm is that you walk the subtree rooted at the select, include a

http://www.w3.org/Bugs/Public/show_bug.cgi?id=12665

Aryeh Gregor <Simetrical+w3cbug@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |Simetrical+w3cbug@gmail.com
         Resolution|                            |WONTFIX

--- Comment #1 from Aryeh Gregor <Simetrical+w3cbug@gmail.com> 2011-06-24 20:08:08 UTC ---
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.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Friday, 24 June 2011 20:08:11 UTC