While true, that does not seem to align with what the checkboxes for firefox, looking at many of the ones that Safari does not support other non chromium browsers don't support on any OS. Mobile or not
The difference is that, on iOS, you can't switch to a different browser that does support these features. Om very other OS you can.
A web app could ask you to use a different browser (not ideal, but if the web app requires a specific API, it's not an unreasonable).
Safari is in a very special position because it controls what the web can do on iOS (all browsers on iOS have to use Apple's WebKit engine, they can't add web features). Apple is not just gatekeeping native (through the app store), but its competition, too (the open web, through the webkit requirement)
True, but putting aside that limitation on iOS for a moment.
The very important part about this is whether or not these features are actually considered a web standard or is it Google pushing their own agenda.
Which is where whether or not any non chromium browser supports any of these on any platform. Which many of these features they don't.
That completely changes the conversation here, from Apple purposefully ignoring standards to Google pushing things that are not standards yet. Which I will admit that the reality is a bit of both here, but it should not be considered a negative when a browser does not support a feature that is non standard... we heavily criticized IE for exactly this and yet we celebrate Chrome for it?
>The very important part about this is whether or not these features are actually considered a web standard or is it Google pushing their own agenda.
Apple is on the W3C board that gets to decide what APIs become standards, so Apple is definitely pushing their own agenda on the W3C.
So you can't really complain that Google is pushing their own agenda with these APIs when Apple is the one refusing to make them a standard. In this case, Apple is the one doing shady shit by holding back things like web bluetooth for no good reason. No, "security" is not a reason, this API has been in use on other platforms for a very long time with no real security issues.
There are lots of other standard APIs that have been implemented, but Apple refused to let the ones that eat into their app store go forward.
>we heavily criticized IE for exactly this and yet we celebrate Chrome for it?
I remember when IE implemented XMLHTTPRequest, and it did a lot of good for the web.
I also remember when Microsoft got an antitrust case for simply bundling IE with Windows, yet Apple seems to get a pass for forbidding all other browser engines on iOS? Well, fortunately Apple has its own antitrust case in the DOJ now for its own abusive business tactics.
Google is also involved in W3C and do I really need to bring up the topics API as Google attempting to use their position to push their agenda as well?
We really need to stop putting google on a pedestal as if they are truelly on the side of an open web, like every company they are looking out for their own interests. Which is fine, they are allowed to do this.
That doesn't change that many of these are in fact not a standard according to W3C and should not be implemented in any browser until it is. A discussion about why it may not be standard is worth it, but that is also a very important distinction that is not made on this page. Right now it is framing it as google supports a standard that the other's (including Firefox) do not.
Just because Google does something it doesn't mean the rest of the industry should follow. If we did that in IE days we would still have ActiveX
> many of these are in fact not a standard according to W3C and should not be implemented in any browser until it is.
That's not exactly how standards work. A browser (or anyone) comes up with a spec, a browser can ship it (to test the waters in an origin-trial, to gain traction if they believe in it), and the standard (often) comes after the fact:
"Working Groups don't gate what browsers ship, nor do they define what's useful or worthy. [...] In practice, they are thoughtful historians of recent design expeditions, critiquing, tweaking, then spreading the good news of proposals that already work through Web Standards ratified years after features first ship, serving to licence designs liberally to increase their spread."
> A browser (or anyone) comes up with a spec, a browser can ship it (to test the waters in an origin-trial, to gain traction if they believe in it), and the standard (often) comes after the fact:
1. Google often doesn't bother even with a spec. Or it creates a semblance of a spec, throws it up on a googler's Github account, ships it and advertises it as "emergin standard" on web.dev
I mean, the status of many (if not most) of the APIs that these sites push are literally "napkin scribble, not on any standards track".
2. Google pushes a lot of APIs quickly into production even if there's a very explicit open objection from other browser vendors (any objections are routinely ignored: from general objections to the shape of APIs to whether it can even be implemented outside Chrome).
3. I wouldn't really quote Alex Russel on anything related to standards, as he is responsible (directly or indirectly) for quite a few of those because of his work on Web Components. E.g. Constructable Stylesheets were shipped in Chrome because Google's own lit project needed them. They shipped it in production when the design contained a trivially triggered race condition, it was called out, and Google completely ignored it because "users want it" or something.
4. Browser vendors quite literally agreed not push incompatible only-exists-in-one-browser shit after the browser wars. The whole standards process is designed to minimize this. Well, Chrome is the dominant browser, so of course they shit all over the process, and quite a few people cheer them for that.
Internet Explorer in the 2000s: shits out a bunch of own non-standard crap, people boo them
Chrome in the 2010s-2020s: shits out a bunch of own non-standard crap, people cheer and blame other browsers for not implementing this crap because... Google is "the champion of open web" or some such bullshit.
>Google is also involved in W3C and do I really need to bring up the topics API as Google attempting to use their position to push their agenda as well?
How is Web Bluetooth an evil agenda of Google??
It's making web browsers more capable. It's not some evil conspiracy to enrich Google. If Apple wants to let the W3C move forward in making it a standard, then all browsers would benefit, and all users that would like to use a bluetooth enabled web-app would benefit.
The only one that benefits from not allowing it to become a standard is Apple, because they get to force developers to make a native app, where Apple can extract a % of sales through the app.
>Just because Google does something it doesn't mean the rest of the industry should follow. If we did that in IE days we would still have ActiveX
IE was the first to implement XMLHTTPRequest. It changed the web fundamentally, and was the basis for "web 2.0". Everyone was glad that they created it, standards or not when it was first implemented.
If we didn't have browser manufacturers pushing the limits, we'd be stuck with "web 1.0" and browsers that did nothing interesting outside of loading animated gifs of dancing babyies.
Never said it was, notice how in the thing you quoted I said "Topics API"? That is extremely evil and was only introduced to benefit a single company, Google.
I never made a claim that every single thing on this list that safari does not support is a negative.
> IE was the first to implement XMLHTTPRequest. It changed the web fundamentally, and was the basis for "web 2.0".
Fantastic, that is an example of things working as they are supposed to work.
However IE also introduced things that were not made standard just as equally we celebrated that those things failed.
> If we didn't have browser manufacturers pushing the limits, we'd be stuck with "web 1.0" and browsers that did nothing interesting outside of loading animated gifs of dancing babyies.
Obviously that is true or the companies would not be involved in W3C. But that does not mean that every idea they introduce is necessary in a browser and deserves to be a standard feature. Google alone cannot and should dictate a standard, even though apparently we are fine with them attempting to do just that.
If everyone is in agreement instead of it benefiting a single company.
> The only one that benefits from not allowing it to become a standard is Apple
I would like to point out, once again. That this feature is also not available on Firefox for Android or Desktop. Your argument does not support why Mozilla has not implemented this feature. Which again, makes the "Apple bad" spin on this not as cut and dry.
A web app could ask you to use a different browser (not ideal, but if the web app requires a specific API, it's not an unreasonable).
Safari is in a very special position because it controls what the web can do on iOS (all browsers on iOS have to use Apple's WebKit engine, they can't add web features). Apple is not just gatekeeping native (through the app store), but its competition, too (the open web, through the webkit requirement)