Let's add tests for several types of inputs. Also, add a test for more a distant ancestor being disabled.

We'll probably also want a guard... if I correctly understand #174 (comment), then IE6-7 are still hanging out to dry.

We'll probably also want a guard...

+1

Thanks for the notes - I have additional tests ready to go. Is there a convention for where new stuff should go in the index.html testbed? I broke a bunch of n-th tests by just adding a form in the middle - but there was definitely nothing explicitly in the index.html about which tests are going to be relying on which elements.

No convention. Adding any HTML could be problematic given the specificity of some of our test selectors. It's just something we deal with.

Node.js test is failing this test - browsers are passing it. Not sure how to proceed on this!

Exactly the same as IE6-7... break this assertion out into a "disabled fieldset (#174)" test and put in a userAgent guard so the broken phantomjs and IE clients skip it. 😢

I'm not sure I completely understand the way the previous assert works, which is why I created a new assert - but it looks to me like some bytes could be shaved by integrating this into the previous assert, directly after the other push of :enabled, :disabled - IE8 won't run the test, but it will have already added enabled/disabled to buggyQSA (right?) and the triggering of the opera error doesn't seem to rely on the div content at all.

The checking I just did, which I actually find hard to believe, suggest that it's not just IE8 throwing an exception on div.querySelectorAll(":enabled"), but IE8-11+ (that's right, even the latest available IE rejects :disabled and :enabled)! If that's correct, then this whole additional assert is unnecessary because any selector containing those tokens will fail and fall into our engine anyway. Unless isDisabled logic can fix another broken client, it looks like all you need to do here is update the range in the L653 support comment.

I think that also answers your confusion about the preceding assert (IE8 executes nothing after div.querySelectorAll(":enabled"), including rbuggyQSA.push( ":enabled", ":disabled" ), and only Opera 10-11 execute rbuggyQSA.push(",.*:") because other clients will have errored on div.querySelectorAll("*,:x") [which you correctly identify as independent of the div content]), but feel free to follow up with other questions. There's lots of pro-compression shortcuts in assert, like exception trapping and automatic div creation.

Not sure how you tested, but I'm not getting any exceptions on :enabled or :disabled on IE11 on Windows 7 by just typing into the console.

I think I just found my problem: running the query on a detached node straight from document.createElement, which throws syntax errors on IE. It's worth noting because that's precisely what div is in the assert callbacks, so for this to work you'll want to do something like docElem.appendChild( div ).innerHTML = … à la L526.

Nice catch, will do.

The "fix" depends on the presence of the isDisabled prop - so should I test for it here? I seems extraneous since there are no known browser environments that would produce the error, but wouldn't have the isDisabled prop, on the other hand, adding the test now might future proof the code a bit.

Sorry for the delay in getting back to you, but this particular mess troubled me enough that I filed a bug with the HTML standard: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24782

Until that's cleared up, let's just drop the option:disabled testing.

If you don't mind, I'm going to quote your notes from that issue:
referencing: http://www.whatwg.org/specs/web-apps/current-work/#selector-disabled

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>

I'm completely behind dropping option testing. Will check that in ASAP.

I checked to make sure that putting:

^(?:input|select|textarea|button

into it's own variable and then doing a RegExp didn't save bytes - it didn't.