This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 24782 - As observed by https://github.com/cmcnulty/sizzle/blob/sizzle-174/test/unit/selector.js#L977-L990, implementations differ on when option elements are actually disabled, specifically when they descend [...]
Summary: As observed by https://github.com/cmcnulty/sizzle/blob/sizzle-174/test/unit/s...
Status: RESOLVED INVALID
Alias: None
Product: WHATWG
Classification: Unclassified
Component: HTML (show other bugs)
Version: unspecified
Hardware: Other other
: P3 normal
Target Milestone: Unsorted
Assignee: Ian 'Hixie' Hickson
QA Contact: contributor
URL: http://www.whatwg.org/specs/web-apps/...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-02-24 05:15 UTC by contributor
Modified: 2014-03-08 01:00 UTC (History)
3 users (show)

See Also:

Attachments

Description contributor 2014-02-24 05:15:31 UTC 
Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/common-idioms.html
Multipage: http://www.whatwg.org/C#disabled-elements
Complete: http://www.whatwg.org/c#disabled-elements
Referrer: http://www.whatwg.org/specs/web-apps/current-work/multipage/

Comment:
As observed by
https://github.com/cmcnulty/sizzle/blob/sizzle-174/test/unit/selector.js#L977-
L990, implementations differ on when option elements are actually disabled,
specifically when they descend from disabled optgroups but also to some extent
when they descend from disabled selects. The strictest reading of current
specification language has option elements never matching :disabled (since
they are not actually a "form control"), but allowing a little more
flexibility would suggest that :disabled perfectly reflects the "disabled"
attribute, which I believe is held to only by Internet Explorer (see
http://jsbin.com/bahejega/3). It would be nice to have a little more detail in
the standard, even if it affirms an above interpretation.

Posted from: 50.163.115.148
User agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/32.0.1700.107 Chrome/32.0.1700.107 Safari/537.36
Comment 1 Ian 'Hixie' Hickson 2014-02-24 18:36:47 UTC 
Safari, Firefox, and Chrome all get the same result here:
   http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2838
This is also exactly the result that the spec requires:
   http://www.whatwg.org/specs/web-apps/current-work/#selector-disabled

The current text for :disabled doesn't mention the phrase "form control", so I'm confused about the report above.

Can you elaborate? Can you quote the text you think mentions form controls, for instance, so that I can understand where that came from? What result does IE get on the dom viewer test above?
Comment 2 Richard Gibson 2014-02-24 19:56:36 UTC 
"form control" was coming from http://www.whatwg.org/specs/web-apps/current-work/#concept-fe-disabled, but upon closer inspection I see that I navigated there by a misclick. The standard is, in fact, clear.

As for the DOM viewer :disabled test, I see failures with the following clients:
* IE (all versions) erroneously fails to match o2 (option in a disabled group)
* Safari<6 erroneously matches o3 (option in a disabled select)
* Safari 6.0  erroneously matches o3 (option in a disabled select) and fails to match g2d; o2 (disabled group; option in a disabled group)
* Opera<15 (Presto) erroneously matches o3; g4; o4 (option in a disabled select; group in a disabled select; option in a group in a disabled select)
* Android (all versions) erroneously matches o3 (option in a disabled select)

<select id=s1><option disabled id=o1d></select>
<select id=s2><optgroup disabled id=g2d><option id=o2></select>
<select id=s3d disabled><option id=o3></select>
<select id=s4d disabled><optgroup id=g4><option id=o4></select>
Comment 3 Ian 'Hixie' Hickson 2014-03-08 01:00:09 UTC 
Those Safaris, Opera, and the WebKit browser in Android are all obsolete at this point, from a Web rendering engine perspective. (That old browsers get this wrong is unsurprising.) Sad to see about IE, but hopefully they'll fix it in due course.