Heads up, a number of these effects don't appear to work correctly in Safari. For instance, the first, second, fourth, and fifth in the top row have a distracting flash in the middle of the animation.
(Even if you consider Webkit and Blink largely the same, 2.5 engines is much better than 2.)
I know a number of people including myself who pretty much ignore Safari for small projects because they don't have iDevices to test on and Safari doesn't run anywhere else. In that instance you just stick to the standards and either hope Safari will cope or don't care if it doesn't.
Even on larger and/or professional projects I see it given second class support: people make sure their project works on Safari, so no show stopper or nasty UX bugs, but display glitches and non-major performance issues that are Safari specific get very low priority, if they are addressed at all.
Currently the differences seen are far less stark than those seen between IE6/8 and other browsers so this is a relatively minor issue, but it might not remain so.
In projects aimed for a wide audience though and for which mobile is a key platform, Safari support is forced much as old-IE support has been forced upon those of us writing software for large institutions who are slow to update, because nothing else runs on iOS. iDevice users can be pretty vocal and not quick to blame their own devices, and even ignoring the noise they can generate they tend to be people with disposable income so if your project/product is commercial you probably can't go too far down the road of ignoring Safari.
In related news, the new Edge will be released for macOS. I think Apple should follow suit with Safari on Windows again (shouldn't be too much work, since they already have the build and toolchain from a while back).
And, uh, Apple's programs for Windows have a history of being really bad. Possibly done intentionally, but even so...
For small/personal projects they need to be free and, for some of us, available offline (I often tinker locally while travelling through low/no signal areas). Do you know of any that fit that bill?
Even with free and convenient tools some will resent needing to test on an extra platform at all just because Safari is slow to adopt new ideas or implements them partially/buggyly.
> 2) same logic applies to mobile
Incorrectly, but yes it does. Which is why you often see "doesn't work on mobile" or "works badly on mobile" in comments here and elsewhere. Mobile is a more general thing than supporting Safari though and a battle in its own right: it is more about accounting for small screens, no physical keyboards, touch-only, low power CPUs, etc.
> 3) iPhone has up to 80% share in many locations,
If a project is not optimised for (or not working at all on) mobile generally, then iDevices having x% share of mobile for particular populations becomes irrelevant. 80% seems rather high for any given population though, could you state any for which this is definitely true?
> Macs up to 25% share in some demographics
You are not potentially cutting these people off by not supporting Safari though, as they have the option of using other UAs unlike users of iOS based devices.
I use PWA, SPA, CSS, SVG, the works and don't have any issue with Safari and iOS rendering the way I expect it to alongside Chrome and Firefox