We use vendor prefixes in our EDD stylesheet. I suggest removing them since browser support is so decent now.
We use -webkit and -moz. There is 1 instance where we already use box-shadow with no vendor prefixes.
Safari 4 (the last version before it was supported) = 0.01% global usage.
Firefox 3 (the last version before it was supported) = 0.01% global usage.
We use -webkit and -moz. There are 2 instances where we use border-radius already with no vendor prefixes.
Firefox 2 (the last version before it was supported) = 0.01% global usage.
Safari = Supported since the first version listed of 3.1 in 2008
We use -webkit, -moz, -ms and -o.
Safari 5 (the last version before it was supported) = 0.01% global usage.
Firefox 4 (the last version before it was supported) = 0.01% global usage.
IE 9 (the last version before it was supported) = 0.15% global usage.
Opera 11.5 (the last version before it was supported) = 0% global usage.
We use -webkit, -o, -ms and -moz.
Safari = Supported since the first version listed of 3.1 in 2008
Firefox 3 (the last version before it was supported) = 0.01% global usage.
Opera 10.1 (the last version before it was supported) = 0.01% global usage.
IE 8 (the last version before it was supported) = 0.22% global usage
We use -webkit, -o, -ms and -moz. We also use another keyframes block with only the webkit vendor prefix so it looks like we only care about Safari, but this is very well supported.
We use -webkit, -o, and -moz. We also use animation elsewhere in the CSS and only use the webkit prefix.
Firefox 4 (the last version before it was supported) = 0.01% global usage.
Safari 5 (the last version before it was supported) = 0.01% global usage.
Opera 11.5 (the last version before it was supported) = 0% global usage.
We use -webkit and -moz.
Safari = Supported since the first version listed of 3.1 in 2008
Firefox - Supported since the first version listed of 2 in 2006
We use -webkit, -o, -ms and -moz.
Firefox - Supported since the first version listed of 2 in 2006
Opera 12.1 (the last version before it was supported) = 0.04% global usage.
Safari = Supported since the first version listed of 3.1 in 2008
IE 9 = (the last version before it was supported) = 0.15% global usage.
Love it. :+1:
My only concern here, is that IE8 actually still has a 4.36% usage in the past month of 2018 in Iran, which is the country where our 2nd most used Locale is (Fr_ir) at 13% of all reported locales for EDD.
Are they getting any of those benefits in core? Not sure what the latest they support is these days.
WordPress core currently has this listed on their browser support:
Last 1 Android versions.
Last 1 ChromeAndroid versions.
Last 2 Chrome version.
Last 2 Firefox versions.
Last 2 Safari versions.
Last 2 iOS versions.
Last 2 Edge versions.
Last 2 Opera versions.
Internet Explorer >= 11
Browsers with > 1% usage based on can I use browser usage table
Source: https://make.wordpress.org/core/handbook/best-practices/browser-support/
The problem I have is we are their 'business model', not their platform. So if we kill some of these UI elements we're affecting their sales engine where as WordPress core is really just affecting their backend experience in the admin, the themes are handle the front end.
To be clear, I'm not saying _no_ to the whole concept, just raising the concern that we need to make sure we realize the implications of cutting browser support for our 2nd most used locale and their browser market share.
We'll probably have to make some post on the developer blog about it to make sure people are aware it's coming.
@amdrew I know we discussed this a bit at the retreat. Did we come to the conclusion that we'd be 100% functional, but wouldn't have feature parity for the browsers I've mentioned above?
Another option is to automatically add them via a post processing/build step. That exact brower list can be targeted and the correct prefixes added: https://github.com/postcss/autoprefixer
@cklosowski We'd be 100% functional if we cut out all the vendor prefixes, however IE 8 would lose support for the animated spinner. I have a sneaky suspicion this has never worked in IE 8 but going to double check (downloading a windows ISO file for vmware).
I'll post back with my findings (hotel wifi... :( )
Edit: iso file is 11.5gb, impossible to download on hotel wifi. Will test when I get home.
@amdrew honestly at this point if we are 100% functionally fine, I say go for it.
I just want to confirm that we aren't breaking sites.
Yeah, it's just animation, won't break anything.
According to https://www.w3schools.com/cssref/css3_pr_animation-keyframes.asp, IE 10 was the first browser to support the CSS @keyframes rule, so although I can't test it just yet, I'm almost certain that the EDD spinner icon has _never_ actually animated in IE 8 anyway.
If this can be redone from release/3.0 instead, we can merge it in easier/sooner.
We've separated and renamed the files a bunch, so it probably won't reverse merge without conflicts.
馃憤 Will re-submit against release/3.0.
New PR: https://github.com/easydigitaldownloads/easy-digital-downloads/pull/6983
Re: https://github.com/easydigitaldownloads/easy-digital-downloads/issues/6928#issuecomment-427143431:
I downloaded a Win7/IE8 image file and can confirm that we never supported IE8. There were no spinner icons (at all) in testing, and when adding items to the cart, the green tick next to the confirmation message doesn't show.
@amdrew but functionality wise everything works correctly? Items are in the cart and behaviors are normal?
@cklosowski Yep, it's not pretty (no icons are loading, including the spinner when purchasing or switching gateways) but it works. I added a few downloads to the cart and purchased successfully with the test payment gateway.
@amdrew then I'm :100: good with this. functionality is really the only thing I wanted to make sure was good to go :+1:
All good for me against 3.0. :+1: