-540-577-867 -856 bytes.

I recommend reviewing with whitespace changes ignored (e.g. viaadding?w=1 to the URL) to see real changes inxhr.js that got de-indented.

A few open questions:

1. I removedsupport.cors &support.ajax - are we OK with always assuming they're true? I'm not sure if IE 11 allows to disable native XHR as earlier IE did or if we still want to cater to those scenarios (we don't support the ActiveX versions anyway).
2. In a few places (e.g.src/data/Data.js) we don't delete stuff from DOM nodes, instead setting them toundefined. It's supposedly to help with DOM performance in Blink/WebKit; the ticket referenced there is not available to the public, though. Do we know if this is still true and if it maybe applies to Gecko as well or not? I'd tweak the comment then.
3. wrapMap.js references IE 9 directly in two places. Most of the file is covered by the comment the wrapping is needed when used in XHTML; is that not true foroption as well? We should either moveoption handling to be under the same XHTML-related comment, remove it or update the support comment if it's still needed for IE 11. Update: this code has been removed from the PR.
4. curCSS.js references thatelem.style is retrieved before the computed style as it fixes some issue in Firefox where it gets wrong values on detached elements. I couldn't find any relevant test or any more details about the supposed issue, could you help,@timmywil, as you committed the change? This has been removed as the workaround that needed it is gone (it was neeeded for iOS 10 only).

BTW, dropping support for iOS 10 & Firefox 60 (which we'll most likely do before the 4.0 release as we'll drop them around September/October) will cause a further reduction by -272 bytes, getting us to -812 bytes compared tomaster and only+14 bytes compared to latest2.2.x. Here are relevant changes on top of this PR:mgol@724f955.

I ran tests locally on this PR on most of the supported browsers:

Per the discussion at the today's meeting, I changed the format of IE support comments from:

// Support: IE <=9 - 11 only

to:

// Support: IE <=9 - 11+

I added one more commit removing IE 9-related code fromwrapMap.js - I run some manual tests in XHTML mode and it didn't seem to cause any changes. The original wrapping of<option> in<select> was added in14b0902 (12.5 years ago!), it was changed to be wrapped in<select multiple> in264ffbc. Removing that wrapping does make more tests fail in IE 9 but IE 11 still passes all the tests.

This removal saved additional33 bytes. 🍾

@jquery/core I've been thinking that maybe we should just drop Firefox 60 & iOS 10 in this PR as well. We'll do that anyway in October and it's not very likely we'll release 4.0 before that date. Especially dropping iOS 10 would give us a lot - it has a partially broken module support, early versions had partially broken Shadow DOM support, etc. Dropping it would help not only with library size but also it'd be easier to do all the upcoming major changes like the event system refactor, getting rid of Sizzle etc. if we didn't have to care about iOS 10 and breaking any of current workarounds targeted at it.

If, by any chance, we manage to land all those major changes, release an alpha/beta & then stable before we'd normally drop Firefox 60/iOS 10 (not very likely, IMO), we can always update the browser support page for jQuery 4.0 to state explicitly we don't support those browsers. We could later remove that note once they'd be out of our supported browser range anyway.

I already have relevant changes ready atmgol@724f955, I could just merge it to this PR.

What do you think?

I agree on the timeline, it seems likely that 4.0.0 could wait for those older browsers to drop below the threshold where we'd need to support them. It definitely cleans up some things!

I added a commit dropping Firefox 60 & iOS 10. We can drop it if others disagree with me,@dmethvin &@jbedard but I think it makes sense to do it now.

We're down to-867 bytes!