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.
Is there a feature-detect we can use to detect unsupported browsers before we load jQuery? I’d really rather not resort to browser sniffing. From memory, IE7 doesn’t have the global JSON object, but Safari 5 does, so that won’t be good enough criteria by itself.
I think so
there are many Internet Explorer 6 uesed by front end developer.Believe it or not?
Excellent stuff, jQuery team! Nice to see such a well-reasoned, data-informed decision.
When I saw the opening sentence “With Microsoft ending Windows XP support this month…” I was worried jQuery 1.x was doing to drop IE8 support (which statcounter says has 6.2% globally, but Net Applications — the folks Microsoft looked to for ie6countdown.com — says it’s over 21%).
But I should have trusted you guys better than that. Nice one!
Maybe next year or the year after, we’ll be able to waive bye-bye to IE8 as well. Maybe.
Is it correct to assume that once IE8 support is deemed unnecessary, jQuery 1.x will officially end and jQuery 2.x will be the main library?
@Ron, use conditional comments to load jQuery 1.12 (or lower) for IE7 and below. It’s much safer than indirect feature testing (what if another non-IE browser doesn’t support window.JSON?).
@Stephen Yes, that’s the plan. We don’t expect it to happen any time soon, though. A few more years will be probably needed…
@Ron I don’t think jQuery will totally break in Safari 5.x, we’ll just remove workarounds so API responses will be different. Note, though, that it won’t happen before 2015 and I don’t think by this point many people will be on Safari 5.x. I’d just leave it as-is, if jQuery breaks then JavaScript will be effectively off so users will get degraded experience (but still OK if you design the page with progressive enhancement in mind).
Bad idea. Don’t drop IE7 suppprt. Don’t do it. Spluitting jQuery in two version is bad enough, and now this?!
Windows XP’s EOL does NOT mean IE7 is EOL, too. Bear in mind that IE7 is the default browser on Vista, and I suspect many corporations use it. You can’t reliably look at global statistics of public websites when deciding on browser support in a framework, because many MANY of these Vista/IE7 boxes might not even have an internet connection, and many MANY sites are intranets – exactly the type of sites accessed with archaic browsers.
What’s more, by not supporting IE7, you’re neglecting local usage of it. In some countries that may seem alien to us westerners, like China or India (totalling 2.5 billion potential users) are less eager to upgrade.
Will the IE quirks mode in IE8+ be supported?
@Richard, quirks mode has never been supported in any version of jQuery, and the team never tests with it. Be sure to have a valid doctype at the top of your document.
@Martijn, every version of jQuery from 1.12 back to 1.0 should run on IE6 and IE7. Take your pick. It seems likely that sites supporting IE6/7 at this point will not be interested in moving to the latest jQuery in any case, their designs need to be dumbed down to the lowest level even to work. So there’s no point to undertake the large amount of tedious work it requires to ensure those old browsers work.
I used to care about supporting IE 6-8, but at this point I’m less worried. By the time you move to IE 8+ I’ll be ready too!