[policy, no patch] Drop IE9 and IE10 support from Drupal 8.4.x

I'd still go for the full proposed resolution in the issue summary.

Wouldn't dropping support for browsers be considered breaking backwards compatibility, which is against the goals for the 8.x releases?

Decide that as of Drupal 8.3, we will no longer accept non-security bug reports that only affect IE10-

That part seems pretty extreme to me. (See also discussion in #2390621: [policy, no patch] Update Drupal's browser support policy and #1030090: Document our browser support list about A-list, B-list, and C-list browsers.)

The rest seems reasonable.

@DamienMcKenna no the bc policy covers the public API. Browser compatibility is neither an API nor part of that policy.

However our browser support matrix is not clear at all, hence this issue and others to try to clarify/decide exactly what it is and document it.

@catch: Thanks for the clarification.

Should this be postponed while #2842298: [policy, no patch] Drop IE9 and IE10 support from Drupal 8.4.x is worked out?

IE 8, 9, and 10 entered end-of-life on January 12, 2016 on most platforms. But Vista is supported until April 2017. Cool.

We cannot innovate on this project by supporting browsers the OS vendor doesn't support anymore and have been automatically warning users about for one year. So, I am a big +1 on forgetting IE 10 ever existed in 8.3.

Changing version given the issue title is ...support from Drupal 8.3

Also changing "annoying" to "hard and costly" since this issue shouldn't happen because IE is unpopular with core developers - it should happen because it makes sense for us to do it.

I'm certainly not against dropping old IE support, but isn't the usual advice to check your site's usage data before you do? (i.e. do we collect version info for accesses of drupal.org?)

This isn't for Drupal.org, it's for Drupal core. Also Drupal.org is running on Drupal 7, which this policy won't necessarily apply to.

There's been a lot of discussion about browser usage in the past, but it varies massively depending on where the data is collected from, and within that regionally etc. Not only that but people administering sites (and especially visiting Drupal.org) are more likely to use newer browsers than site visitors. This makes it impossible to have an 'objective' discussion about browser usage, so a lot of the discussion in #2390621: [policy, no patch] Update Drupal's browser support policy is about trying to find a browser support policy that's more straightforward and based on what browsers people are able to use on different operating systems vs. hold outs.

I think the remaining steps to mark this fixed are to:

1. Update the handbook requirements/browser policy documentation. (Someone needs to do some digging to see which handbook pages would need an update.) We need to provide specific language about how we don't support them, but we also aren't deliberately breaking them, etc.
2. Make a change record.
3. Announce the policy change on g.d.o/core.
4. Mention it in the release notes and CHANGELOG for the appropriate release.

All the release managers agreed on this policy. Leaving the other tags as while @effulgentsia is in favor as he filed the issue, neither that nor @alexpott's comment isn't a signoff per se, and there is no product feedback on this issue yet. So that's step 0 actually.

Yeah, needs a CR. That's how we handled this in the past.

Made provisional update to the Recommended target browsers page (which can/should be tidied up once 8.3.0 is actually out).

All framework managers are +1 to this, so removing tag.

Later today after my comment, the framework and release managers agreed to move this to 8.4.x, since the jQuery UI update did not make it into 8.3.x, and all future improvements for ES6 and so forth will also only happen in 8.4.x anyway since 8.3.x is shortly to be in RC.

Thanks @wturrell for starting on the documentation fixes!

Marking the issue NW to add the needed change record as well.

Later today after my comment, the framework and release managers agreed to move this to 8.4.x, since the jQuery UI update did not make it into 8.3.x, and all future improvements for ES6 and so forth will also only happen in 8.4.x anyway since 8.3.x is shortly to be in RC.

Thanks @wturrell for starting on the documentation fixes!

Marking the issue NW to add the needed change record as well.

Also updating the summary to reflect the move to 8.4.x.

Adding a news:

officially ending support for Internet Explorer versions 8, 9, and 10, starting with WordPress 4.8.

https://make.wordpress.org/core/2017/04/23/target-browser-coverage/

It's not clear when we talk about Drupal's supported browsers, whether we mean within the CMS as a site editor (eg the Drupal editing tools, add/edit node, WYSIWYG toolbar etc), or as an anonymous visitor. Or do you mean both?

Somehow i missed that issue. Good news :)

Ok, thanks for the clarification effulgentsia. Do we expect the contrib space to be able to fill the gap and provide support for IE 9 and 10, in the same way that ie8 is currently enabling 8.0 - 8.3 to work with IE 8?

@nicrodgers contrib could provide a jquery_downgrade module which reverts back to 2.* releases, the opposite of Drupal 7's jquery_update.

Our own JavaScript hasn't yet changed to rely on features in the newer jQuery versions or that aren't supported IE9/10 so it'd just be a case of switching back to older jQuery at the moment. This might change in the future though so it'd get more complicated then.

I'm currently working on implementing a module to provide Content-Security-Policy headers, which runs into a small issue due to IE 9 still being supported.

Since IE9 only supports 31 stylesheets per webpage, if there are more CssCollectionRenderer outputs them within an @import statement instead of as <link> elements. This means that style-src 'self' can't be used, and instead style-src 'self' 'unsafe-inline' is needed.

Enabling CSS aggregation should reduce the number of stylesheets on the page below the threshold of 31 items such that they can be output as <link> elements, so production sites should not be affected if this particular support for IE9 was removed.

Created #2897408: Remove IE9 support from CssCollectionRenderer and provide it in contrib instead

Reviewed this issue with @effulgetsia.

Speaking as a product manager, and having reviewed a few different sources for browser usage data (StatsCounter, NetMarketShare and consistently see IE11.0 as the only version of IE that ranks. The Internet has clearly shifted to Chrome as the default browser, and IE8 has more marketshare than IE10+9 combined. :P

And even if we dig in on a specific region like China, which has been problematic in the past for these kinds of decisions due to widespread adoption of XP/IE8, http://gs.statcounter.com/browser-version-market-share/desktop/china#mon... we still see IE8 having a higher marketshare than either IE9 or IE10.

Therefore, I think we're good to go on this. I think we should follow jQuery UI's lead, in that we shouldn't exactly go out of our way to break things for IE9/10, but we also shouldn't hold back innovation for these browsers from 8.4.0 on.

Draft change record created at https://www.drupal.org/node/2897971.

This is unclear. It compares to jQuery UI and makes me feel we have the same standard. But it actually sounds like only remains the fixes until the first release: 8.4.0?

jQuery foundation able to make their decision case by case (not only on security issues). and jQuery & UI have very clear @support annotation. And they seldom restructure the CSS without bug fixes I think.(There's 2 years development time between 1.11 & 1.12). Which means when jQuery UI said remains the fixes, we could expect it works until 1.13.

However, in Drupal in this case. We able to introduce and refactor CSS. Do we start breaking changes from 8.4.1?

Starting use new innovation in new Component (eg. experimental module) VS Able to refactor code in the current features. It's a huge diff from my mind.

@droplet it seems you have questions about when and what we can change in the CSS after making this jQuery update? But I think the main question is if we should drop support for IE versions below 11. Do you agree with that? If we still need to clarify the impact of this change then we should do that, but it would be good to have your yes or no about which versions of IE to support :)

Version 11 seems to be the only version of IE that still registers in these usage numbers, so sounds sensible to me.

@yoroy,

The decision is made. I have no right to vote Yes or No :p My answer isn't important. I also gave my comments in different of these IEs posts already.

Now, I only want to know:
1. when will drupal start to remove older IE fixes. 8.4.1 or 8.5.0?
2. And when can drupal introduce IE11+ only changes, 8.4.1 or 8.5.0?

This is very important to our own development. (and when I review patches in d.org)

Thanks for clarifying @droplet.

1. when will drupal start to remove older IE fixes. 8.4.1 or 8.5.0?
2. And when can drupal introduce IE11+ only changes, 8.4.1 or 8.5.0?

We probably need a new issue to create a version of https://www.drupal.org/core/d8-bc-policy for CSS and JavaScript.

For pure-refactoring patches, we'd probably only do both of those changes in the next minor release (which currently could include 8.4.x, but will very soon mean 8.5.x), in the same way that PHP refactoring only lands in the later version.

Changes required to fix bugs, or in experimental modules, could land in both branches though.

@webchick the change record looks good. Since we have that, should we mark this to RTBC?

Opened #2898533: Better define the backwards compatibility/API policy for JavaScript for #39, I think we can continue discussion of what changes we should allow when there, close this issue, and publish the change record?

This is now mentioned in the release notes and I've publish the change record, with some small changes: https://www.drupal.org/node/2897971/revisions/view/10579669/10590748

I corrected it to say "Internet Explorer" instead of the insider "IE" shorthand, and also added the information that we are removing existing workarounds for them beginning in 8.5.x rather than 8.4.x.

Followups:

• #2899055: Update Babel transpile targets to match Drupal supported versions
• #2897408: Remove IE9 support from CssCollectionRenderer and provide it in contrib instead
• #2390621: [policy, no patch] Update Drupal's browser support policy