Description

With jQuery 4.0 dropping support for lots of legacy browsers, currently (on master) all of our support tests only fail in IE. This is not a surprise as IE 11 is the only browser we support that's not getting updates. I'd like to consider relying on document.documentMode to detect IE in such cases.

First versions of jQuery relied on user agent parsing for applying workarounds. Later, that was changed to rely on support tests. What problems did the original approach have?

1. If a browser fixed the bug, the workaround was still applied in it, needlessly penalizing it.
2. Another browser using a similar engine may also have a bug but the workaround wasn't applied there if its UA didn't match our check.
3. Another browser using a similar engine may not have the same bug as a browser with a similar user agent that we test on but it'd be penalized anyway.
4. An update to the browser may change its user agent, breaking our check.
5. The workaround may rely on the bug itself, meaning that if the browser fixed that bug, jQuery would break in it. This may prevent browsers from fixing issues.

Let's address those points one by one:

1. There are no future IE versions planned. Edge with EdgeHTML was its continuation but its development stopped as well (and I wouldn't plan to cover Edge with this approach). While we can't have guarantees what will happen in the future, I'd rather not optimize for improbable edge cases - and this point is just about needless workarounds, in such an unlikely event an updated IE would still not break jQuery.
2. There's enough code on the internet (e.g. in various web frameworks like AngularJS) in which IE workarounds are guarded by documentMode checks that any Trident-based browser with removed documentMode would face lots of troubles anyway. Also, we don't have to support such browsers apart from IE. Plus, with Trident being closed source forks can't freely edit the engine for their needs as they can do with e.g. Chromium.
3. Modern browsers are being based on modern engines, Trident isn't one of them. See point (1) - I'd rather not optimize for improbable edge cases.
4. A documentMode check is not a user-agent check. Parsing user agent strings is inherently fragile, here we'd just check for thuthiness of document.documentMode. Any IE update removing documentMode would break lots of code in IE already.
5. To make sure that in the unlikely event IE fixes a bug we workaround it won't break us, we can run tests in Chrome Headless with document.documentMode set to 11.

I'd like to note that historically we haven't relied on support tests fully. In some cases we lumped a few issues under a single support test that didn't carefully check them all. I'd have to look a bit more for specific links to discussions, though.

What would be the gains of relying on documentMode?

• We'd save 410 bytes gzipped
• We'd avoid executing support tests which takes time, especially the boxSizingReliable test that requires a layout. This may matter for cheap mobile devices with limited power (see the analysis of parsing time in an old TJ VanToll's article.
• Using documentMode to detect IE is used in AngularJS/Angular, Ember, React & many others. We wouldn't be alone in this.

To make it clear, here is what I do NOT propose:

• I don't propose skipping writing support tests completely. While my branch doesn't have any, if we hit an issue in a modern browser, I'd expect us to write a support test as we've done so far (recently for Firefox around version 60). This proposal only affects IE-related support tests.
• I don't propose relying on any piece of the user agent.
• I don't propose using the documentMode check for workarounds that would break if IE fixed the issue (which we'd verify by a special Chrome Headless run).

As an experiment, I did the proposed rewrite on a branch (see the latest commit). It also has the proposed special Chrome Headless run set up. Initially, it failed one test in this "fake IE" mode - the SVG dimensions one. This is because the workaround depends on offsetWidth/offsetHeight which are only available in IE. This shows, though, that the workaround already depends on the browser with the bug being IE. I added a separate check to skip the workaround if offset* properties are not supported on SVGs which makes the tests pass.

What do you think?

Link to test case

N/A