Ask HN: What Web Standards does Safari/WebKit not implement | Hacker News Reader

Ask HN: What Web Standards does Safari/WebKit not implement

17 pointsJcowell24 comments

A reoccurring argument I see in the Safari/Webkit v.s Other Browsers/Engines debate is that Safari does not adhere to standards. Usually these come down to a feature either:

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.

View on HN

> ...is implemented but half-baked, doesn’t work...

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.

A small but illustrative example is lookbehind assertions in regular expressions. Example regexp is /(?<=foo)bar/ which matches "bar" if preceded by "foo". This is standardized in ES2018 and remains unsupported in JSC (WebKit's JS engine).

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...

https://caniuse.com/?compare=edge+102,edge+103,firefox+100,f...

I’m finding caniuse unhelpful as I’m seeing non standardized/experimental API’s included with no label of distinction. This goes against the scope of the post as I’m looking to discuss standardized API that Safari/WebKit does not implement (for example WebMidi was a good one given earlier). I find caniuse harmful in this discussion due to it’s lack of status/standard label in it’s table.

Are you asking this genuinely to find some items that Webkit doesn't implement, or are you coming in with the conclusion already that WebKit implements everything. Just saying since your replies here seem to be arguing the latter without giving benefit of the doubt to the original posters.

E.g. if you really want to learn what features safari may not have, why not actually go down cyanydeez's post and eliminate each as not real standards. Unless this is a "do my homework/persuasive paper at job for me", they've already provided the pointer and if you really want to learn, going through the list one by one on your own time is probably high ROI.

> Are you asking this genuinely to find some items that Webkit doesn't implement

I’m trying to find standard items that WebKit doesn’t implement. Comment chains usually devolve like so:

X: “Safari doesn’t implement Z feature I like and chrome does”

Y: “Z feature is not a web standard but a chrome pushed feature”

Conversation ends and then repeats on another thread. Over and over and over again. Chrome-backed features muddy the discussion we should actually be having: What standards does WebKit not implement and why

Since caniuse lacks the labeling of what stages an API are in , it’s a misleading answer to a very specific question. A better answer would be a link to MDN web docs that does show if a feature is experimental and shows browse capability (all though not to the extent that caniuse can)

> or are you coming in with the conclusion already that WebKit implements everything

No. It doesn’t make sense to make a thread actively searching for standards not implemented. I could’ve just not if I believe foolishly that Safari implements everything.

> if you really want to learn what features safari may not have, why not actually go down cyanydeez's post and eliminate each as not real standards

More so than wanting to see what feature safari may not have, I believe HackerNews will benefit from an outright guided discussion. Could I do it? Sure I’m hell right tempted to take caniuse & MDN web Docs data and export them out as a categorizable & filterable table of standard, experimental, and exclusive API’s but I believe this approach is far more engaging. It is something I’m actively experimenting in my head about how to go about it.

Fair enough!

Standard autocomplete="off" attribute/value pair they've refused to implement since 2015.

Really good one. Blanket disrespect for the autocomplete attribute.

https://caniuse.com/?compare=firefox+101,chrome+103,ios_saf+...

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.

While I agree that Safari doesn’t implement a lot of features , the intention of this post is about what features it doesn’t implement, but what standard features it doesn’t. As I recall , APIs like Web Bluetooth and WebUSB are experimental features.

Does caniuse differentiate features that are full web standards or in draft stages? I’m looking for a tool that does so but it seems none of them do.

A lot of these are used to fingerprint users to better track them for advertisement industry (https://www.wired.com/story/browser-fingerprinting-tracking-...)

I feel (but have no substantial reason) that the subtext of this sudden governmental interest in this issue is more so the fight between the lobbies of ad-supported tech giants (Google, Facebook) and Apple

The iPhone still doesn't support the fullscreen api. It makes it almost impossible as a web game developer. Extremely frustrating.

Another good one , while iPadOS has support , iPhones , like the op said, does not. One can only speculate this is done as a measure for web apps to not compete against native apps. To me that’s very anticompetitive.

My first thought is wondering how you exit full screen on a touch device if the developer doesn't happen to add it into the UI? On the desktop it's easy, just hit the Esc key. How does the iPad handle it?

A pinch gesture (Zoom out) cancels it. Very unhelpfully, it also places a hovering X in the top left corner that never goes away. It covers up an area of the screen that a lot of sites would use for a hamburger menu / home link.

iPhones also prevent background playback of videos (so no listening to YouTube) — as well as autoplaying a second track after a first, manually played one ends (so no web audio players which are not streaming).

Here's an in-depth article:

https://infrequently.org/2021/04/progress-delayed/

For more up-to-date things, check the rest of Alex's blog.

webmidi, web speech - which they say they support but got randomly removed. They support only a crippled version of the pwa apis, and their store doesn't support verified pwas like the android one does.

In regards to WebMidi I believe a previous HackerNews conversation has captured the discussion nicely[1]. Though I doubt these are WebKits only concern. What are your thoughts ?

Are you referring to web speech being the one randomly removed ? I thought it was in Safari but not unless the user enables dictation. It seems it was removed from SafariViewController and web apps due to needed implementation details[2].

I don’t believe PWA’s are a standards but more so a sum of standards depending on the application (for example a game PWA will use more API’s than a non game PWA) so depending on what the PWA is, it needs may or may not be covered. I’d like to the keep the scope of the post limited to specific standards as I believe it would be more productive.

[1]: https://news.ycombinator.com/item?id=23676109#23679063

[2]: https://bugs.webkit.org/show_bug.cgi?id=225298

CSS flex is still flaky in WebKit almost a decade on. It used to be equally flaky in Chrome, but it is now better in Chrome

Thankfully grid support in Safari is solid

webm (on iOS)

jpegxl

Immediately come to mind.

Both are really good ones.

For anyone invested in jpegxl you can follow the bug tracker here[1]. Though upon research I’m confused , isn’t jpegxl still in experimental phase of other browsers (this of course doesn’t exempts WebKits outright not implementing at all)

[1] https://bugs.webkit.org/show_bug.cgi?id=208235

I've been a lot of people bring up jpegxl over the past few weeks/months. When I looked into it, all browsers that had support hid it behind a feature flag. User's have to go way out of their way to enable it as it's not ready for prime time yet. I think that falls under the "still in beta" category.

Safari is not giving anyone a worse experience by not supporting jpegxl yet, as no one should be using it outside of a tech demo, since I'm sure 99% of users will not have support enabled.

Reply on news.ycombinator.com