You can compare with Firefox by clicking on the Chrome icon – even enable both to see only features supported by both. (I think it would be a nice default view, though.)
I think the feature to compare could be made a little more obvious - I can see why they would default to Chrome (both the most popular browser & also the one that shows the starkest difference), but tbh I find the most interesting comparison being against macOS Safari - that list seems really surprising to me.
This also would of course be even nicer if you could define any browser as the "target" (e.g. compare Chrome -vs- Firefox) but then that wouldn't serve their very nice domain purchase as neatly.
Yeah, I would like to know more about the Mac vs iOS WebKit as well. I would have guessed that the development of both would be done by the same team and that it would be very close for all features where they didn’t take a strategic decision to hinder web apps on the phone or performance/ux. But for example not having the autofocus attribute or pseudo selection css seems a little strange even though I can see how it could affect ux on the phone, especially the autofocus which would show the keyboard.
I think it's normally "harebrained" like hare/rabbit but hair brain doesn't imply any greater intelligence for sure. I've said folks are "single threads" to indicate something similar in more nerdy settings.
Geez was staring at this trying to find icons and didn't realize on mobile the bottom drawer wasn't just part of the browser. Good stuff. Took this fun milk carton concept to a usable next level.
It seems wrong to mix and match actual accepted standards with things that only Chrome implements which are not standards.
Should iOS adopt [feature] because Chrome has it, or why else is it on the list? What benefits am I missing as a user?
As a mainly desktop Firefox user, any time I have a web bug my developer colleagues asks me to try Chrome instead because they only develop and test in Chrome. I would say if we care about standards and an open web we should not cater so much to Chrome's whims and wishes…
In practice, I've never missed an API on Safari for building websites that customers ask for. I have missed Chrome dragging it's feet on CSS properties like Snap Points or backdrop-filter.
The difference in culture couldn't be any more apparent, with this website having a complete disregard for users as it's actual content is just rendered into an image, not available to basic web browser functionality like copy and paste.
While the visualization is cool, I hope some of these will remain "not found" indefinitely. Just because we can stick everything into a web-spec, doesn't mean we should.
Weren't some of these like WebUSB and WebBluetooth unilaterally pushed by Chrome without going through the usual spec processes? Firefox doesn't have them either.
All the dangerous ones come with comprehensive permissions prompts, and browsers can offer options for don't ask again/never ask etc, so if you're not interested there's still little downside to those being available for those who are.
Personally, I've found a bunch of these super useful, as user and a developer. Being able to use tools like https://www.espruino.com/ide/ to play with hardware straight from the web is amazing.
We already have a diverse ecosystem of platforms which are capable of using hardware components for various experiences - we call them "the OS". It comes with a security model, permission prompts and all kinds of bells and whistles (it's a mature platform, developed for decades).
The browser (agent) is a native app designed to allow users to access and navigate web resources (we call them pages or documents). Pages can be styled (CSS) and made interactive (JavaScript).
When one wants to create an experience which goes beyond the scope of the browser, one builds another native app that is able to leverage the needed resources. A dedicated native app can embed a browser (e.g. webframe) or consume web resources through other protocols. A native app can also request access to hardware resources via the OS.
The desktop might be quite diverse, but the diversity on closed, proprietary ecosystems like iOS is controlled by one party. Either, we open up iOS so anyone can distribute apps without Apple being the ultimate authority (like on MacOS), or we enrich a much more mature platform (the web) that we already have to be more capable so we can deliver very similar experiences through the web that we currently build native apps for. Compared to iOS, the web platform is more secure with better privacy controls [1][2], and that feels like a better place to invest our energy.
I'm not sure how the close aspect of iOS is relevant, it feels like a strawman.
You say the web is more mature, to which I reply that this is the same circumstance as leaving one browser to become dominant (which we already did). In a perfect world, having a closed option would be "one of the options on the table" but for the majority of users this is not the case.
Introducing WebUSB (or any of the more exotic features on the list) will not help us towards an open platform. On the contrary, it will only worsen the dependence on a handful of corporations that can afford to invest to build a browser. Remember, even Microsoft couldn't afford to continue working on their own engine.
As a developer, I care very deeply about being able to make my apps and experiences available to "all the platforms" but shifting the cost of compatibility into userland is not a long term solution. Just put yourself in the shoes of a traveller, struggling to pay for their last-minute plane ticket at the gate but being greeted with "Sorry, our checkout page doesn't work on your browser/device". This is not the way.
The closed aspect directly speaks to how much diversity you can have on the platform. The features (like WebUSB) aren't the drivers for a more open platform, but they highlight what the impact of having no competition does. Opening up the platform will fuel competition and the market can decide what works and what doesn't. At the moment, we just have to trust Apple has our best intentions by supporting/not supporting certain features and standards. However, we know from the work the Open Web Advocacy has done that this isn't true. The primary driver for both stifling progress on Safari and keeping browser competition out is the profits from the App Store [2].
Chrome becoming the dominant browser is also concerning, and they will have to be held to a much higher scrutiny by us and policy makers to ensure they have users best interest at heart [3].
> shifting the cost of compatibility into userland
What do you mean by this?
> struggling to pay for their last-minute plane ticket at the gate but being greeted with "Sorry, our checkout page doesn't work on your browser/device". This is not the way.
I agree! This is exactly why we can't depend on one organization to dictate what's allowed and disallowed on that platform. On iOS, think about how long it took Apple enabled Apple Pay support for non-safari browsers even though they all had to be WebKit-based.
I would guess that most regular users are very quick to click “Allow” on a dialog box. I like how macOS handles unidentified apps where you have to navigate manually to the security settings to allow an unidentified app.
For dangerous ones like WebUSB you can't just click 'Allow' - after granting permission, it shows you a list of connected devices, and you have to actively select the device you want the website to access, and then approve it.
Even something as simple as auto-focus on a form field on page load... imagine that your keyboard jumps up and takes up half of your screen space, just because a web-dev wanted you to be able to "immediately input your name". I'm actually quite happy that my iPhone doesn't shove a keyboard in my face "for my convenience of being able to input text immediately".
The web lacks intentionality that installed 'native' apps have. You search for a recipie and land on a random blog, executing untrustable code from a countless number of third parties, clicking "I agree" on that modal that says "LiveLaughLove blog and out 1382 partners value your privacy".
Native apps have a much higher level of friction at multiple points that helps balance the higher level of access they get.
The APIs coming with a security or privacy risk are always gated by a permission prompt on the web (contrary to platform-specific apps). Safari has gone even further by only allowing some of them (e.g. Push notifications) for installed web apps.
These APIs are also much more restricted than their proprietary-ecosystem equivalent.
Overall, web apps having access to these features in Chrome are an order of magnitude safer than platform-specific apps.
Because some of us lived through pop up hell and Microsoft’s lack of security as it relates to web browsers in the late 90s/2000s. Web apps should be as restricted as possible.
Rich companies such as Epic, complaining about a 30% cut can cry me a river. Lock iOS down as much as possible and restrict/sandbox the web.
iOS is the only internet connected computer I’ve had that didn’t get malware and/or a virus at some point. Unless you consider an Xbox/PlayStation a computer.
And would you build for all browsers or just your favourite "standard"? It doesn't matter how many layers we add, it will always amount to the same challenge when people use different systems. That's why it's generally better to target a solution with the least amount of abstractions to depend on. Build a native app, you depend on the OS. Build a PWA, you depend on the browser and the OS.
As for the 30%, How long do you think it would be before Chrome decides to monetize their web apps? The Manifest v3 story was a hint, maybe not everyone got the memo.
Because there's typically at least a minimum of safety checks before an app can go into the app store, whereas a website can do whatever it wants (and can).
They belong in the browser engine so that they could be used by a web-app that is presented and served as a standalone app. They do not belong in the scope of just any website out there.
I agree with you. Notifications is another “feature” I just want to stay out of my browser. To that extent, I actually don’t mind Safari on iOS being deliberately slow to adopt some of the more intrusive standards.
You might want to ping HN admins (email works best in my experience) to reposition this post in HN since it has been nuked out of the atmosphere for some reason. It is nowhere to be seen in HN listing.
For example this other post is older (6 hours ago), with less points (70) and less comments (34), and yet it shows on top 12 of HN:
12. Show HN: a Rust based CLI tool 'imgcatr' for displaying images (github.com/silinmeng0510)
And what are they suggesting to improve the proposal? Apple, which makes $20B a year with Safari, surely has enough resources to make a counter-proposal?
The counter-proposal is: don't do it. This comment by the Apple guy sums it up well IMHO:
> Colleagues and I have discussed this and don't see a way to grant write access to the end user's local file system in a way that safeguards the end user's interests.
So they can make it to work for platform-specific apps that they tax 30%, but can't make it to work for interoperable web apps which they can't tax. How convenient.
It's able to support this because the 'file system' is scoped specifically to that origin, and doesn't allow access to any aribtary location on the file sytem, just like iOS.
If Apple made arbitrary file access work for apps [1], surely they could make it work for Safari. But apps pay 30% and websites don't, so it's easy to conclude why they don't want to.
I think there is a pretty secure approach of doing it.
1) When loading a file, nothing needs to be different from the already available upload functionality. The user picks the file to load.
2) When saving a new file, nothing needs to be different from the already available download functionality. The user picks the name and the place to save it.
Only after 1 or 2 have already happened can the page request to update the file. With the same name and location. In this case, the user gets a prompt that explains the risks and asks the them to confirm the update.
The list doesn't tell the full story though, my biggest problem with it is that it's overall a buggy browser. I've encountered bugs on localStorage & indexDB, forms, SVG and CSS overflow, buggy border radius on videos (not sure if this one is fixed now) all of those being very basic web features.
I feel like they lack a lot in the QA side of things, it doesn't feel very polished.
I'd be more accepting of Safari if it would be more polished and had a better release cycle (it's also the last major non-evergreen browser), all the next gen features are good sure, but not a replacement for those problems.
We’re crying at a pretty high level IMO. So many cool APIs are available now in all browsers that enable us to build things that used to be impossible on the web.
I don't really see it as a problem that other browsers don't immediately implement non-standard, underspecified APIs some Googler made and put into Chrome to get a promotion.
It's a problem when Apple refuses to implement standards because it hurts their 30% cash cow monopoly, but most APIs on that site aren't that.
Off topic: We don't have missing people on milk cartons here in Europe. Seeing them always reminds me of being a teenager, watching Blur's Coffee and TV music video on MTV: https://www.youtube.com/watch?v=6oqXVx3sBOk
I don’t think I’ve ever seen a missing person on a milk carton in the US either. It is only something I’ve seen in TV and movies, and I’m in my 40s. My assumption is that this was a thing from the 1950s, but someone who grew up during that era would have to speak to it. I suppose it’s also possible it was a regional thing and I wasn’t in a region that did it.
Excellent, thanks. So it sounds like I was alive, I was just either in an area where it wasn't used, or too young to remember, before it faded from popularity.
It’s amazing something so short-lived had such an impact.
I guess that they are missing for good reason? Web notifications? Sparsely useful, 99% is just some clickbait website trying to feed you junk. Thanks Apple! The website look cool tho.
One that stood out was the audio element being able to read the volume, but not set it. Apple has always had the stance that user preferences like this should only directly be changed by the user, not by an application. There are 2 convenient buttons on the side of my iPhone, there is no need for any website to ever be able to mess with my volume settings.
The website would not be able to mess with your volume settings. The implication of this choice by apple is that you cannot play two sounds at different levels, for example.
The original intent for iOS was for developers to use Safari, not making native apps. For apps that won’t pass the Apple approval process, Apple’s direction is still for them to make we apps.
I’m seeing a lot of “draft”, “candidate”, “recommendation”, and “other”. Aka, I’m seeing a lot of bullshit.
Yes, Apple has dragged its feet on standards but things that Chrome just decided on by itself are not standards.
A number of the partially implemented (on iOS) things (like clipboard or volume) have legitimate privacy concerns or UX concerns. I don’t want a website to read my clipboard, I don’t want a website to change my volume.
There are some more legitimate looking things but a number of those are not part of the spec according to this very website.
I’ve said for years that Chrome is closer to IE in writing their own standards and Safari is closer to IE in conforming to the standards. But blanket “Safari is the new IE” statements are just silly and miss the forest for the trees.
That has nothing to do with my point that these aren’t web standards in most cases. Walled gardens are a separate concern. You can’t point to things that aren’t standards and talk about walled gardens.
> Typically, cutting edge features are deployed by browser makers in their own engines first, then, using real world feedback over several years, eventual standards are created. No feature starts out as a web standard. – Walled Gardens Report, Open Web Advocacy [1]
Apple dragging it's feet will impact this, but Apple outright banning competing browser engines kills all progress. Having competing browsers on the platform will allow the market to decide what features are useful and what are not, and the standards can follow suit. I agree there are privacy concerns with some of the proposals (especially some of the ones by Google), but not having the choice of browsers is much worse for the open web.
At the moment, we just have to trust Apple has our best intentions by supporting/not supporting certain features and standards. However, we know from the work the Open Web Advocacy has done that this isn't true. The primary driver for both stifling progress on Safari and keeping browser competition out is the profits from the App Store [2].
Eh. The thing I miss the most: stop reloading pages/tabs when switching back to safari (or any browser, since it's all the same webview).
If apple wants to treat the web like documents, that's fine, but then don't make it suck like an app. If a page is loaded, there is NO reason to randomly reload it because iOS deems it has been too long. Maybe it's a general problem with iOS killing apps in background, I don't care, it sucks.
That's more or less how HTML has always been. Before Chrome, it was IE just adding stuff. Before IE, it was Netscape just adding stuff. JavaScript itself is just a browser adding stuff.
Like it or not, W3C standards have always been reactive to what browsers are already doing.
And what's really remarkable about this list is that quite a few are supported on Safari on Mac, just not on iOS. Like autofocus. It's just a simple attribute you can put on an <input> tag that autofocuses that element when the page loads. It's on Mac Safari. It's on Android browsers. It's just not on any iOS browser because, you have to assume, someone at Apple held it back for not very good reasons.
The difference specifically for autofocus being that the keyboard will appear when that happens on iOS, whereas on your Mac the keyboard is always out regardless of focus. I can see how that would be annoying.
> That doesn’t mean that we should just adopt any nonsense that Google comes up with.
That's a fair statement. Conversely, why should we put up with Apple stifling the web platform? Especially when there's strong evidence to show this is motivated primarily by profit rather than the user experience [1][2].
Its up to us developers to stop using functions only provided by one browser.
I find it absolute madness that anyone would use an API in their code which is only available on Chrome. If its not a standard which is not supported by the 4 main browsers, then its not going in my code.
This is a good example of how the chromium monoculture hurts the web. It ends up being Google's way or highway.
EDIT: You can filter by features that both Firefox and Chrome support by tapping the Chrome icon. This takes the list from 63 entries to 29
This also would of course be even nicer if you could define any browser as the "target" (e.g. compare Chrome -vs- Firefox) but then that wouldn't serve their very nice domain purchase as neatly.
Should iOS adopt [feature] because Chrome has it, or why else is it on the list? What benefits am I missing as a user?
As a mainly desktop Firefox user, any time I have a web bug my developer colleagues asks me to try Chrome instead because they only develop and test in Chrome. I would say if we care about standards and an open web we should not cater so much to Chrome's whims and wishes…
In practice, I've never missed an API on Safari for building websites that customers ask for. I have missed Chrome dragging it's feet on CSS properties like Snap Points or backdrop-filter.
The difference in culture couldn't be any more apparent, with this website having a complete disregard for users as it's actual content is just rendered into an image, not available to basic web browser functionality like copy and paste.
The text is actual text.
I must have disallowed selecting for the swiping feature to work. Definitely something I should look to revert or allow for copying buttons.
While the visualization is cool, I hope some of these will remain "not found" indefinitely. Just because we can stick everything into a web-spec, doesn't mean we should.
Personally, I've found a bunch of these super useful, as user and a developer. Being able to use tools like https://www.espruino.com/ide/ to play with hardware straight from the web is amazing.
The browser (agent) is a native app designed to allow users to access and navigate web resources (we call them pages or documents). Pages can be styled (CSS) and made interactive (JavaScript).
When one wants to create an experience which goes beyond the scope of the browser, one builds another native app that is able to leverage the needed resources. A dedicated native app can embed a browser (e.g. webframe) or consume web resources through other protocols. A native app can also request access to hardware resources via the OS.
[1] https://open-web-advocacy.org/walled-gardens-report/ [2] https://changelog.com/jsparty/316#t=00:25:59.26
You say the web is more mature, to which I reply that this is the same circumstance as leaving one browser to become dominant (which we already did). In a perfect world, having a closed option would be "one of the options on the table" but for the majority of users this is not the case.
Introducing WebUSB (or any of the more exotic features on the list) will not help us towards an open platform. On the contrary, it will only worsen the dependence on a handful of corporations that can afford to invest to build a browser. Remember, even Microsoft couldn't afford to continue working on their own engine.
As a developer, I care very deeply about being able to make my apps and experiences available to "all the platforms" but shifting the cost of compatibility into userland is not a long term solution. Just put yourself in the shoes of a traveller, struggling to pay for their last-minute plane ticket at the gate but being greeted with "Sorry, our checkout page doesn't work on your browser/device". This is not the way.
Chrome becoming the dominant browser is also concerning, and they will have to be held to a much higher scrutiny by us and policy makers to ensure they have users best interest at heart [3].
> shifting the cost of compatibility into userland
What do you mean by this?
> struggling to pay for their last-minute plane ticket at the gate but being greeted with "Sorry, our checkout page doesn't work on your browser/device". This is not the way.
I agree! This is exactly why we can't depend on one organization to dictate what's allowed and disallowed on that platform. On iOS, think about how long it took Apple enabled Apple Pay support for non-safari browsers even though they all had to be WebKit-based.
[3] https://open-web-advocacy.org/walled-gardens-report/#the-chr...
You don’t need to do that, you can just right-click the app and choose “Open”.
Native apps have a much higher level of friction at multiple points that helps balance the higher level of access they get.
These APIs are also much more restricted than their proprietary-ecosystem equivalent.
Overall, web apps having access to these features in Chrome are an order of magnitude safer than platform-specific apps.
Rich companies such as Epic, complaining about a 30% cut can cry me a river. Lock iOS down as much as possible and restrict/sandbox the web.
iOS is the only internet connected computer I’ve had that didn’t get malware and/or a virus at some point. Unless you consider an Xbox/PlayStation a computer.
https://medium.com/online-io-blockchain-technologies/the-evo...
As for the 30%, How long do you think it would be before Chrome decides to monetize their web apps? The Manifest v3 story was a hint, maybe not everyone got the memo.
I'm Shalanah. I made iOS404.com.
A couple of feature notes:
- Compare to other browsers by clicking on the Chrome icon to switch to FF for Android or Safari Desktop (or a combo).
- Select or deselect specification by clicking on the filter icon.
On what's to come: I'm looking to add MDN features next. There are wayyyyyy more missing iOS features there.
Thanks! -Shalanah
For example this other post is older (6 hours ago), with less points (70) and less comments (34), and yet it shows on top 12 of HN:
Because with it, we can offer users to hold their data natively on their devices. Instead of storing everything in the cloud.
So far, I think only Chrome on the desktop supports it. Here is a nice demo:
https://googlechromelabs.github.io/text-editor/
A text editor that works just like a native application.
https://github.com/mozilla/standards-positions/issues/154
https://github.com/WebKit/standards-positions/issues/28
Neither Mozilla or Webkit are satisfied that the proposal is safe by default, and contains footguns for the user that can be pretty destructive.
> Colleagues and I have discussed this and don't see a way to grant write access to the end user's local file system in a way that safeguards the end user's interests.
https://developer.mozilla.org/en-US/docs/Web/API/File_System...
https://webkit.org/blog/12257/the-file-system-access-api-wit...
It's able to support this because the 'file system' is scoped specifically to that origin, and doesn't allow access to any aribtary location on the file sytem, just like iOS.
If Apple made arbitrary file access work for apps [1], surely they could make it work for Safari. But apps pay 30% and websites don't, so it's easy to conclude why they don't want to.
[1] https://developer.apple.com/documentation/uikit/view_control...
1) When loading a file, nothing needs to be different from the already available upload functionality. The user picks the file to load.
2) When saving a new file, nothing needs to be different from the already available download functionality. The user picks the name and the place to save it.
Only after 1 or 2 have already happened can the page request to update the file. With the same name and location. In this case, the user gets a prompt that explains the risks and asks the them to confirm the update.
https://github.com/mozilla/standards-positions/issues/154#is...
But very cool site. And I definitely think Safari should have some of these! It's a bit cruel on them! Hahaha! :)
I feel like they lack a lot in the QA side of things, it doesn't feel very polished.
I'd be more accepting of Safari if it would be more polished and had a better release cycle (it's also the last major non-evergreen browser), all the next gen features are good sure, but not a replacement for those problems.
So don’t only focus at what isn’t here yet.
It's a problem when Apple refuses to implement standards because it hurts their 30% cash cow monopoly, but most APIs on that site aren't that.
It’s amazing something so short-lived had such an impact.
Yes, Apple has dragged its feet on standards but things that Chrome just decided on by itself are not standards.
A number of the partially implemented (on iOS) things (like clipboard or volume) have legitimate privacy concerns or UX concerns. I don’t want a website to read my clipboard, I don’t want a website to change my volume.
There are some more legitimate looking things but a number of those are not part of the spec according to this very website.
I’ve said for years that Chrome is closer to IE in writing their own standards and Safari is closer to IE in conforming to the standards. But blanket “Safari is the new IE” statements are just silly and miss the forest for the trees.
Google is definitely not in the clear, but Apple's anti-competitive practices is much more damaging to the open web.
> Typically, cutting edge features are deployed by browser makers in their own engines first, then, using real world feedback over several years, eventual standards are created. No feature starts out as a web standard. – Walled Gardens Report, Open Web Advocacy [1]
Apple dragging it's feet will impact this, but Apple outright banning competing browser engines kills all progress. Having competing browsers on the platform will allow the market to decide what features are useful and what are not, and the standards can follow suit. I agree there are privacy concerns with some of the proposals (especially some of the ones by Google), but not having the choice of browsers is much worse for the open web.
At the moment, we just have to trust Apple has our best intentions by supporting/not supporting certain features and standards. However, we know from the work the Open Web Advocacy has done that this isn't true. The primary driver for both stifling progress on Safari and keeping browser competition out is the profits from the App Store [2].
[1] https://open-web-advocacy.org/walled-gardens-report/#mandati... [2] https://changelog.com/jsparty/316#t=00:25:59.26
If apple wants to treat the web like documents, that's fine, but then don't make it suck like an app. If a page is loaded, there is NO reason to randomly reload it because iOS deems it has been too long. Maybe it's a general problem with iOS killing apps in background, I don't care, it sucks.
Like it or not, W3C standards have always been reactive to what browsers are already doing.
And what's really remarkable about this list is that quite a few are supported on Safari on Mac, just not on iOS. Like autofocus. It's just a simple attribute you can put on an <input> tag that autofocuses that element when the page loads. It's on Mac Safari. It's on Android browsers. It's just not on any iOS browser because, you have to assume, someone at Apple held it back for not very good reasons.
Also autofocus on page load is a terrible idea on iOS as it automatically brings up the keyboard.
No one wants to switch between web pages and suddenly have to wait for the keyboard to appear each time on page load.
That's a fair statement. Conversely, why should we put up with Apple stifling the web platform? Especially when there's strong evidence to show this is motivated primarily by profit rather than the user experience [1][2].
[1] https://open-web-advocacy.org/walled-gardens-report/ [2] https://changelog.com/jsparty/316#t=00:25:59.26
Expectation on iOS is that anything that is focused you should be able to type into.
I find it absolute madness that anyone would use an API in their code which is only available on Chrome. If its not a standard which is not supported by the 4 main browsers, then its not going in my code.
It's OK to acknowledge that sometimes Google does good stuff.
And some features e.g. long lived first party cookies which are used for retargeting serve no legitimate purpose except to support advertisers.