a) still in beta b) pushed by chrome so not a real standard c) is implemented but half-baked, doesn’t work, or stripped down for privacy concerns.
I think it would be helpful if, instead of arguing wether Safari’s gatekeeping is saving or stalling the web, we list out the things we can’t do that are actual standards and why.
Please be sure not to list anything coming to WebKit in iOS16 as it would lead to redundancy.
We have to discuss that, because malicious compliance of "fine, we'll make a poor implementation so you can't rely on it" is something they may be doing to nudge developers to Apple's "preferred" app system.
IndexedDB... A pillar of the PWA set of APIs (You know, it's kinda handy to be able to save and search structured data locally in adverse network conditions). Their regression testing on this is non-existent. One could maybe forgive a poor initial implementation, but they keep. breaking it. every. other. release. On no other platform do we run into this issue.
Somewhat saved by them aggressively clearing PWA data if not used within a ~"week or two", so if we detect Safari, indexedDB is more used as a sketchy temp cache, and we aggressively try to sync as much as possible to remote to prevent data loss.
FormData is another API, it took them over 2 years to get past having just the append() function after everyone else implemented the full spec. Every other browser you can call set() and be done, Safari? Recreate the FormData object with the modified value.
Date inputs, iOS has incredibly gimped Date inputs to this day (cannot set min/max/step to improve UX by clamping users to relevant date ranges for say, booking an appointment), on desktop it was NON-EXISTANT till Q2 2021, and now it's a also gimped but in slightly different ways to iOS date input.
This feature is difficult to retrofit onto an existing engine, because it requires teaching every construct to track backwards. Among major engines (JSC, SpiderMonkey, v8, and Chakra at the time), only v8 has ever implemented it.
Firefox gained support by just adopting v8's regexp engine wholesale, and I speculate the difficulty of this feature in particular was a major reason. The blog post [1] explaining this decision cited this as one of four ES2018 regexp features that were yet to be implemented, but I know from experience that lookbehinds are by far the most challenging in the list.
"Diversity of regexp engines" is maybe not that important, and Mozilla's decision to adopt v8's implementation is defensible given their resources. Still I think this is an especially clear-cut example of a web standard decreasing browser diversity.
1: https://hacks.mozilla.org/2020/06/a-new-regexp-engine-in-spi...
You can draw your own conclusions. Personally, I think the omission of the vast majority of webapp functionality (Web Bluetooth, WebUSB, WebHID, screen orientation, haptics, etc.) is a real shame, and probably what's really holding back Safari at the moment.
...but what does it matter what Apple does? People aren't angry that Safari sucks (though it certainly doesn't help), rather that they can't choose the browser they use on a device they bought with their own money. I reckon that's a valid concern, regardless of which arbitrary browser feature trinkets WebKit can collect.
https://infrequently.org/2021/04/progress-delayed/
For more up-to-date things, check the rest of Alex's blog.
Thankfully grid support in Safari is solid
jpegxl
Immediately come to mind.