input:disabled doesn't respect disabled parent fieldset #174

Closed
dmethvin opened this Issue Nov 25, 2012 · 10 comments

Comments

Projects
None yet
6 participants
Owner

dmethvin commented Nov 25, 2012

While working on http://bugs.jquery.com/ticket/12134 I was surprised to see that this does work in qSA: http://jsfiddle.net/dmethvin/65QUz/

Owner

timmywil commented Nov 26, 2012

Yea, this in the spec. We've never implemented due to performance implications.

Owner

timmywil commented Aug 27, 2013

I think we'll close this wontfix. Traversing up the DOM to check all possible matches for disabled would probably be horrendous (especially in the browsers that don't support QSA). If anyone wants to provide a patch with perf tests, we'll take a look.

@timmywil timmywil closed this Aug 27, 2013

cmcnulty added a commit to cmcnulty/sizzle that referenced this issue Jan 23, 2014

#174 - fix :disabled pseudo
fix :disabled psuedo for IE

So, it turns out there is a way to address this without traversing up the DOM - IE (8-11 at least) expose a property called isDisabled which tracks whether or not something has inherited disabledness. So, just a couple lines of code for a new sizzle supports, and testing a different property in the disabled pseudo selector...

That brings the pseudo selectors in line with each other regarding disabled fieldsets, which in turn also fixes places like serialize() which use the :disabled selector internally.

There's a little more to it to make sure we support options as consistently as we can within each browser - they make different decisions regarding whether an option inherits the :disabled state of a disabled select/fieldset/optgroup - with different and completely inconsistent answers with each browser, naturally.

Anyway, here's a pull request: #244

I sleep now.

And here's where we encountered the bug in the real world: ivaynberg/select2#2030

IE6-11 all use the isDisabled property, so that's good. I've found some funny things while researching this one - for instance Although IE6 doesn't support disabling options in any way - when you try to disable them, they'll report as .disabled = true AND .isDisabled = true, even though they're both editable and submittable.

Also, Native IE6 select's don't inherit the disabledness from the fieldset (and at least the properties don't lie about it), however the IE6 document mode of IE10 unbreaks that bug, rather than re-implementing it honestly - which gives validation to this old gem: http://www.paulirish.com/2011/browser-market-pollution-iex-is-the-new-ie6/

Member

mgol commented Jan 27, 2014

@cmcnulty

Also, Native IE6 select's don't inherit the disabledness from the fieldset (and at least the properties don't lie about it), however the IE6 document mode of IE10 unbreaks that bug

AFAIK there's no such thing as IE6 document mode, only 5 (quirks), 7, 8, 9, 10 & edge.

Correct you are. It's ie7 and 5 document mode implementation that fix the selects-don't-inherit bug.

cmcnulty commented Apr 2, 2014

Worth noting that at least once this has been closed as WontFix by Microsoft:
https://connect.microsoft.com/IE/feedback/details/722689/fieldsets-not-targeted-by-disabled-pseudo-class

phazei commented May 26, 2016

Will sizzle 2.3 be included in jQuery 2.x? I just noticed that jQ3.x is on it's way. If I install sizzle 2.3 on its own, will jQ use it?

Member

gibson042 commented May 27, 2016

The team opted not to include Sizzle 2.3 in jQuery 2.x, but you can get this particular improvement by loading Sizzle yourself and copying over the pseudos:

jQuery.expr.pseudos.enabled = Sizzle.selectors.pseudos.enabled;
jQuery.expr.pseudos.disabled = Sizzle.selectors.pseudos.disabled;
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment