Silverstripe-framework: VOTE: Do you or your clients use IE10?

Created on 18 Nov 2016  路  18Comments  路  Source: silverstripe/silverstripe-framework

Currently we have agreed to drop IE8 and IE9 support for SilverStripe 4. However, we had not yet decided whether IE10 or IE11 would be the minimum version.

Please note that when talking about browser support we refer only to CMS usage and not to the browser support of websites built with SilverStripe.

We will definitely support IE11 in SilverStripe as it is not possible to run newer versions of IE on Windows 7, and this is a common configuration for corporate IT environments.

IE11 is supported in Windows 7 service pack 1, and as best we can tell IE10 will auto-upgrade to IE11, so it is likely that IE10 use is limited, even in corporate environments.

We would like to get feedback on whether or not the SilverStripe community currently relies on IE10 support via votes on this card.

Please vote 馃憤 to one of the comments below to cast your vote.

Most helpful comment

VOTE: Neither I nor my CMS authors currently use Internet Explorer 10. Dropping support for Internet Explorer 10 in SilverStripe 4 would not impact me.

All 18 comments

VOTE: Neither I nor my CMS authors currently use Internet Explorer 10. Dropping support for Internet Explorer 10 in SilverStripe 4 would not impact me.

VOTE: I or my CMS authors currently use Internet Explorer 10, but we can upgrade. Dropping support for Internet Explorer 10 in SilverStripe 4 would be acceptable.

VOTE: I or my CMS authors currently use Internet Explorer 10, and it is infeasible for us to stop using it. If SilverStripe 4 does not support IE10 then we won't be able to use it.

Some more references for this:

  • Capability differences: http://caniuse.com/#compare=ie+10,ie+11
  • "On Windows 7, 8.1, and 10, only Internet Explorer 11 will receive security updates for the remainder of those Windows versions' support lifecycles. " - https://en.wikipedia.org/wiki/Internet_Explorer_11
  • "On January 12, 2016, support ended for IE10 on Windows operating systems capable of running Internet Explorer 11, due to new support policies dictating that only the newest version of IE available for a supported version of Windows will be supported. IE10 will only be supported on Windows Server 2012[12][13] and Windows Embedded 8 Standard.[14]" -
    https://en.wikipedia.org/wiki/Internet_Explorer_10

@xini do you have any information about why your clients are unable to upgrade to IE11?

I'd suggest taking the stance of officially supporting IE11+ and then make a "best effort" to support IE10 but not to do so at the sacrifice of features that would otherwise have to be reduced/removed in order to accomplish it.

For example: Don't spend more than maybe 10-30min to resolve a bug in IE10 (such as a quirk in flex box) and certainly don't avoid using native functionality in favor of a polyfill (or even include a polyfill) for IE10 when it's supported natively in IE11 (e.g. WebGL 3D graphics or something).

That being said: Chances are a majority of the functionality would probably be unaffected; they would just likely be left behind on newer features (if they don't break the CMS/page). Also, as an alternative, you could just remain on SS v3 until IE10 is upgraded.

@patricknelson

  • the latest version jQuery UI is IE11+. so we either need to not upgrade, or not support IE10
  • if we don't test IE10 then we'll probably break things and not realise. testing against IE10 is one of the bigger costs of supporting it

Best case scenario will be that we support IE10 for the basics and are more tolerant of minor visual degradations. But, depending on how this survey goes, we may just drop support for it. It's a security hazard to use IE10.

@sminnee one of my large clients is apparently stuck in the past by internal policies. The policies come from their headquaters in the US. Not much we can do from here. But I guess they will eventually come around. By the time SS4 is stabe and all modules are updated so that everything is actually ready to be used, I guess they might be ready to make the switch... might just take a while for them to be able to upgrade. no worries.

Cool, thanks for the info @xini

We have some IE10 users but we usually get them to install Chrome. So IE10 support isn't big for us, would rather see the development time better spent.

Some clients might use IE10 but they would have no problem installing another browser to use the CMS. As long as they get a warning that their current browser is not supported, dropping IE10 support would be totally acceptable for me.

The main area I foresee potential issues with removing IE10 support would be for Government clients. Not sure about in NZ, but here in AU, the upgrade time frame for departmental IT can be excruciatingly slow. For example, I have one Government client that has only just migrated to Windows 7 within the last 12 months, let alone Windows 8, 8.1 or 10. I think they were hitting the CMS with either IE8 or 9, blecch. 鈽癸笍

But, these are exceptional cases; personally I'm all for removing anything but the latest IE support! I urge caution though with dinosaur clients such as these, however.

Windows 7 and IE11 is a common government configuration here. Of 120 sites we checked only 1 had regular use of IE10.

It's worth noting that IT teams running IE10 are compromising their organisation's security.

OK on the basis that a significant minority would need some upgrading form IE10 I think the following would be okay:

  • Remove IE10 from the officially supported browser list
  • Show a clear warning if older versions of IE10 are used to access the CMS but don't lock people out
  • Accept IE10 bugfix PRs that don't substantially increase the code complexity
  • Allow the use of libraries that support IE11+

I just checked with the client and they're on W7/IE11 now, sweet! 馃槃 Your suggestions above sound pretty good, @sminnee. 馃憤

I've added this to the beta1 milestone, since we should be clearly communicating browser support at this point.

I have added #6719 to track the piece of dev work still necessary in response to this card, and closing this off.

I've documented this decision in core now: https://github.com/silverstripe/silverstripe-framework/pull/6764

Was this page helpful?
0 / 5 - 0 ratings