Browser Support in jQuery 1.12 and Beyond

With Microsoft ending Windows XP support this month, we’re giving the jQuery community some long-lead-time notice on changes to browser support.

First of all, don’t panic! Nothing is really changing with respect to the browsers that can run jQuery for at least six more months. Our goal is to let everyone in the web development community know what the jQuery team intends to do over the next year, so that you can plan accordingly.

What’s Changing?

There are no firm dates, but we plan on releasing jQuery core versions 1.12 and 2.2 this year. jQuery 1.13/2.3 will be released some time in 2015.

jQuery 1.12: This will be the last release to support Internet Explorer 6 and 7. As of today, no feature requests or bug fixes will be landed for them. Only serious regressions for these browsers will be fixed in patch releases (e.g., 1.12.1). jQuery 1.13 will support IE8 as its minimum browser.

Both jQuery 1.12 and 2.2: These will be the last releases to support Opera 12.1x and Safari 5.1. As of today, no feature requests or bug fixes will be landed for them. Only serious regressions for these browsers will be fixed in patch releases (e.g., 1.12.1 or 2.2.1).

Both jQuery 1.13 and 2.3: We will remove patches and workarounds that are specific to API conformance for the browsers we no longer support, in order to simplify the code base.

What you need to do: If your projects use a package manager that pulls in the latest release of jQuery, keep in mind that the 1.12-to-1.13 or 2.2-to-2.3 upgrade will reduce browser coverage. You may want to stay on 1.12 or lower if support for older browsers is required. See the instructions of your package manager for details on how to do that.

The Meaning of “Support”

Defining what “support” means is trickier than you might think. Under the premise that “untested code is broken code,” the jQuery core team prefers to say we fully support a browser if the project regularly runs unit tests against that browser. The unit tests ensure that every API returns a consistent set of results in all browsers.

Even when we support a browser, there can be bugs we can’t reasonably fix. For example, Internet Explorer 6 through 11 fire focus and blur events asynchronously and the code required to make them appear synchronous would be significant. Safari on iOS doesn’t support the onbeforeunload event which is pretty much impossible to shim. Until last month, Firefox didn’t respect overflow: hidden on a fieldset element. We try to work with browser vendors to get these bugs fixed.

On browsers that we don’t officially support, we still work hard to eliminate “killer bugs” such as script errors during initialization that make the page totally unusable. If you want to see the lengths to which we go to deal with obscure problems, look at this browser-crashing Android 2.3 bug on Japanese phones which was extremely intermittent and hard to diagnose. With the help of several users we were able to track down and work around the problem.

It comes down to this: We can only ensure high-quality continuing support for the browsers and environments we constantly unit-test. However, we will try to provide some reasonable level of support to browsers in any popular environment. The highest priority will be on ensuring the browser doesn’t throw errors. Low priority will be put on ensuring that old or rare browsers produce the exact same API results as modern browsers.

Who Uses Old Browsers Now?

When looking at browser stats, don’t look at where they are today. Think about where they will be in 2015. All told, we think all these browsers will be in the small single digits of market share by then. If numbers from StatCounter can be believed, these browsers are already there and will be even less prevalent when jQuery finally drops support.

Ultimately these whole-Internet stats don’t matter though. What really matters is whether the visitors to your site or users of your web application are running a particular browser. That is something that only you can answer. The decision to upgrade to a new jQuery version is always in your hands as a developer.

The Myth of Browser Consistency

Today and long into the future, jQuery will still contain dozens of browser-specific fixes to normalize behavior. At this point, the most problematic and troublesome browser for jQuery 2.x is the one in Android 2.3. That version is still a significant 20 percent of the Android installed base, and still being shipped in new mobile products. Several JavaScript features like element.classList are not supported there, and it’s one of the last browsers to still require -webkit-prefixing for standardized CSS properties.

jQuery projects are all about making your development life easier, so we’ll continue to support the fixes that are needed to smooth out inconsistencies on popular browsers. As the market share of specific browsers dwindles to zero, we’ll take the opportunity to remove their patches and de-support them in order to streamline our code bases. That makes all jQuery pages a little bit faster.