Closed Bug 577306 Opened 14 years ago Closed 9 years ago

For disabling options, should only look at the parent optgroup

Categories

(Core :: DOM: Core & HTML, defect)

defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: Ms2ger, Unassigned)

References

()

Details

(Keywords: html5)

Attachments

(2 files, 1 obsolete file)

In the testcase at <http://software.hixie.ch/utilities/js/live-dom-viewer/saved/538>, both options should be enabled, as the disabled optgroup is its parent, but rather a grandparent. See <http://www.whatwg.org/html/#concept-option-disabled>.
Attached patch WIP (obsolete) — Splinter Review
Still need to find a way to test this.
Attached patch Patch v1Splinter Review
Attachment #456294 - Attachment is obsolete: true
Attachment #456431 - Flags: review?(Olli.Pettay)
Attached file testcase
So do you know why html5 defines that behavior.
IMO, it makes more sense to disable everything under a disabled optgroup.

And the patch doesn't seem to work too well with this testcase.
The second option isn't gray'ed out, but user can't select it anyway.
Attachment #456431 - Flags: review?(Olli.Pettay) → review-
We could use the patch in bug 759666 and directly use HasState() on the option element?
Depends on: 759666
I think this is INVALID, because the spec says <option>s that aren't children of the <select> or of <optgroup> children of the <select> are not part of the list of options to start with (bug 1214164).
Flags: needinfo?(Ms2ger)
I'm not working on this bug.
Assignee: Ms2ger → nobody
Status: ASSIGNED → NEW
Flags: needinfo?(Ms2ger)
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: