toolkit
toolkit copied to clipboard
sky-uk
Browser Support
Description
IE9 Styles
As a consumer, I would expect IE9 styles to live with the component, not in sky-toolkit-core. Our current architecture is a little confusing.
or do we need to revisit our browser support?
The evidence is mounting up; not many of our customers are really using IE9 anymore. Should we bother supporting it? As we approach the possibility of [email protected], is it time to revisit our strategy?
Taking a note from Una's talk at All Day Hey;
We should be making use of the newest technology to create awesome innovative experiences. Older browsers don't need to have the same experience, it just needs to be functional.
Attempted Fixes
If we do want to keep IE9 styles, let's create a little @include ie9(); mixin that outputs our properties consistently, whilst keeping all component styles together.
We'll probably have to use @at-root, but I think it'll be tidier.
Context
Enhance Toolkit developer (and customer) experience.
@sky-uk/toolkit-owners brethren and sistren, I am keen to hear your thoughts
We dropped support for IE9 on Mobile Service almost 2 years ago. We still support IE10+ though. I wanted to drop it straight away but the main reason we ended up dropping it is that IE9 doesn't work with GraphQL.
As more teams across Sky are starting to use GraphQL, it might be the reason we need.
I think with TLS 1.2 support for a lot of services being rolled out soon there is a strong case for dropping support for IE9 + 10 as they do not support this protocol. I would be in favour of revisiting the supported browsers for toolkit.
Agreed with all of the above. Across a lot of Digital Trading we're currently supporting IE11+.
This will allow for a lot of specs being fully supported such as Flexbox and Viewport Units, with a lot of other specs only requiring some polyfills for IE11 (CSS Grid, Custom Properties, etc).
We'll also be able to relook at whether we need sass-mq
I have a couple of questions:
- Do we have a policy of supporting browsers that are above a certain percentage of usage?
- Do separate areas/teams of sky.com support different browsers?
The only point I'd raise here is that we shouldn't forget that where people are still on ancient browsers, it's likely because they don't have a choice and have no other option. There's an alternative interpretation which is that they don't have a choice on that specific device, but can easily switch to a different one. Does anyone have any bright ideas as to how we could survey these people rather than guess at what's going on? I'm reluctant to just point at a policy and call it done without understanding a bit more about user behaviour.
@regularfry for me it's all about the quote I've mentioned above:
We should be making use of the newest technology to create awesome innovative experiences. Older browsers don't need to have the same experience, it just needs to be functional.
The key point is whatever we decide, it must still be functional. It just doesn't have to look the same. Which is kinda what we do now with IE9, but our current strategy is more about making things look the same.
@joebell93 agreed. That means it's not a line in the sand, "all bets are off" deal. It's "we support IE9 differently to how we support IE10", not "we don't support IE9".
It's an interesting one to define or write out because it all really depends on the features we want to look into. For example, CSS Grid is supported in most modern browsers.
Perhaps the answer to this is a soft "functionality" line in our browser support list (a guideline that should always be met but could be moved dependent on the feature)
For example, in PR templates:
## Browser Support
- [ ] Chrome
- [ ] Edge
- [ ] Firefox
- [ ] IE11
- [ ] Opera
- [ ] Safari
### Functionality
As a **minimum**, changes should be functional in the following browsers.
This line of functionality isn't set in stone and can be moved to meet the features used.
- [ ] IE9
- [ ] IE10
- [ ] Mobile Devices
- [ ] Screen-readers (e.g. JAWS, Apple VoiceOver)
I quite like the "Class A/B/C/Z" concept (I think YUI did it first). Class A browsers are pixel-perfect, class B is usable though may look different, class C is "try it, it might work but we've not tested it".
That way we can have different lists (with versions) for each.
About a year ago you could make a case for a base level of support for IE9 but I think the time has come to draw the "line in the sand" - looking at Januarys stats for /shop, it's not even in the top 50 desktop browsers (< 0.1%). Unless someone has some compelling stats to say otherwise, I would encourage us to lose any pretence about us supporting it. For other legacy browsers, @Tom-Davidson suggestion above would work nicely.
OK, but that just moves the problem: IE10 is significantly behind IE11, which again is behind Edge.
Which is what we should be doing; we can't drop all legacy browsers but we should be regularly assessing how far back we extend support. Things start to get rosier when we move to an IE10+ world as more modern CSS3 properties are supported - notably Flexbox and Grid (although still pretty buggy until Edge). Not needing to concern ourselves with having to have so many fallbacks allows to embrace more modern practises and push the capabilities of what is achievable. When was the last time we checked something in IE8? At some point we have to leave legacy behind.
As an update to this conversation, I propose we drop IE9 completely in 3.0 and implement the following browser support guidelines:
## Browser Support
- [ ] Chrome
- [ ] Edge
- [ ] Firefox
- [ ] IE11
- [ ] Opera
- [ ] Safari
### Functionality
As a **minimum**, changes should be functional in the following browsers.
This line of functionality isn't set in stone and can be moved to meet the features used.
- [ ] IE10
- [ ] Mobile Devices
- [ ] Screen-readers (e.g. JAWS, Apple VoiceOver)
Looking good but probably worth being more specific on mobile devices. How about last two major versions of:
- Safari for iOS
- Android Chrome
- Samsung Internet? (Custom Chrome?)
Also is it worth we mention that on desktop browsers we support the last two major versions of X and then exceptions for Y and Z
@steveduffin potentially, there's a lot of variation in terms of Android browsers though. Chrome isn't necessarily the default but I guess it's the most popular
We need to drive this thing off data. I'll see what numbers I can get my hands on. Last stats I've got for shop place Mobile Chrome and Samsung Browser as the only two android browsers above 1% of visitors.
BTW Opera (< 0.1%) doesn't even trouble the top 50 so there's a case for dropping that as well
Data alone doesn't cut it, because it ignores the impact to those affected. It's not just a matter of lost sales. 0.1% is still 3,000 visits per day. If we downgrade everyone on a <=0.1% platform, that's over 700,000 visits per day.
Again, if someone today is on an old version of IE, or a funny Android browser, the chances are that they don't have a choice. Right now I'm not aware of any user research being done into what those reasons might be: is this old machines that nobody in the house is confident to upgrade? Are people locked to old versions of JAWS which can't work on more recent browsers? Are we seeing someone's only device with a browser being a cheapy android from 2015?
If we only look at the data in front of us, we're going to lose important questions like this. This is why we need product's input, to understand where there are particularly vulnerable groups that we're going to exclude otherwise.
This is still going to come down to a numbers game as we can't possibly account for every possible permutation but you raise a good point about it not being as easy as drawing a line across a certain threshold when it comes to assistive technology and attainability.
However, I'm not sure the fragmentation of Android would allow us to identify a particular combination of niche but important target devices. The good news is that even feature phones get rolling updates that keeps the software relatively current. Also worth noting that JAWS has supported IE10 for the last five major versions (http://www.sightandsound.co.uk/liveagent/192257-Which-versions-of-Windows-Office-and-Internet-Explorer-is-JAWS-compatible-with) It would be great if we can get more nuanced information on this but we are going to need to work with what information we have available to us and make a call on what we are actively going to target and what accommodations we need to make.
I appreciate what you're saying @regularfry but I don't think we're ever going to get that level of confidence in a user base to make any assumptions at that level. As nice as it would be to understand why a user cannot upgrade, I'd agree with @steveduffin that this will ultimately come down to percentages and what figures the business are comfortable with.
Toolkit has to be a product that grows with the times and if we want to continue to be on the cutting edge of technology then we must evolve and outgrow the older stuff, as has been the case for all browser deprecation.
Its worth mentioning that theres no reason we cannot look to functionally support browsers without fully supporting them at a pixel by pixel level. There's also no reason a specific app cannot provide its own support for an older browser too, if thats a direction we wanted to advocate, although personally I feel like we should treat .com as one app
Its probably worth noting that we haven't been supporting IE9 in Sky Mobile for over a year now and haven't seen any fallout from doing that. Sky Pages hasn't really done so and neither has trading. We eventually have to say that we cant actually support stuff anymore. We eventually have to deprecate support for things. The longer we support something the more it will hinder us. Stats usually don't lie and in the grand scheme of things, 3000 users getting a slightly different visual experience compared to the millions we get on more up to date browsers really isn't the end of the world and is really not that bad.
The numbers aren't quite that straightforward. If we say "Browsers at <=0.1% aren't supported", that's 4% of visits in total. Set it to 0.3% to justify binning IE10, and it's nearer 8%. The long tail is long.
We get more visits from Amazon Silk than we do from all IE versions <11 combined, but I'd be less worried about breaking Amazon Fire TV sticks because they're unlikely to be the only browser in the house that's already got an HDMI TV and broadband.
We have conflicting needs here: as devs we might want "cutting edge", but a shared toolkit needs to accommodate the lowest common denominator. As long as that's true, the baseline support level ought to come from those with the widest version requirements. We can be guided by data, but shouldn't be dictated by it.