iOS404(ios404.com)
ios404.com
iOS404
https://ios404.com/
100 comments
[deleted]
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.)
Thanks! I totally missed that
[deleted]
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.
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.
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.
Right you are! I guess I'm one of today's 10000
With the help of a generation of developers hating Microsoft and IE, Google has managed to turn the Web into ChromeOS.
Hi all - this is quite fun!
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
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
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:
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)I just emailed HN via the contact below. Not sure if that's the right method -- thanks the tips!
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.
So don’t only focus at what isn’t here yet.
So don’t only focus at what isn’t here yet.
If problems aren’t called out they can’t be solved.
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.
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.
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.
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.
I'd highly recommend this document to establish the scale of impact these different vendors have: https://open-web-advocacy.org/walled-gardens-report/
Google is definitely not in the clear, but Apple's anti-competitive practices is much more damaging to the open web.
Google is definitely not in the clear, but Apple's anti-competitive practices is much more damaging to the open web.
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.
I think this has a lot to do with your points.
> 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
> 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
[deleted]
Looks awesome!
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.
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.
Me too. Device orientation, USB, Bluetooth, vibration, they don't belong in a web app.
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.
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.
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.
Also known as “yes click syndrome” or “make the stupid thing work already”, a phenomenon which can be and has been weaponized.
> where you have to navigate manually to the security settings to allow an unidentified app.
You don’t need to do that, you can just right-click the app and choose “Open”.
You don’t need to do that, you can just right-click the app and choose “Open”.
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 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.
[1] https://open-web-advocacy.org/walled-gardens-report/ [2] https://changelog.com/jsparty/316#t=00:25:59.26
[1] https://open-web-advocacy.org/walled-gardens-report/ [2] https://changelog.com/jsparty/316#t=00:25:59.26
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.
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.
[3] https://open-web-advocacy.org/walled-gardens-report/#the-chr...
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 describe the problem and how the web solves it quite well.
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".
Why would they belong in a platform-specific app but not in a standard-based web app? Because Apple can't get 30% out of it?
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.
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.
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.
https://medium.com/online-io-blockchain-technologies/the-evo...
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...
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.
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.
They absolutely do, if well implemented they are no more risk than any other API. The web can be what java wanted to be, if we don't screw it up.
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.
Also clipboard reading and volume change, no thanks.
I didn't understand why these APIs existed until I used ESPHome. It can use the Web Serial API to flash an ESP32 board using Chrome + a USB cable.
Many of these belong into a web app, the problem is that browsers can't distinguish between a web app and a web site.
Correct, we need to be hiring 3x the amount of programmers to make our apps on 3 platforms instead of one, webusb is killing jobs!
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.
TBH Bluetooth is useful for Xiaomi e-paper clock-thermometers which can't be set without a Mi Home app... smh
And some things aren't great on mobile but make more sense on desktop. Autofocus doesn't cover half my screen with a keyboard when I'm on my laptop...
Sometimes, it's about what you take away. Good design is not when there's nothing more to add, but when there's nothing more to take away.
But very cool site. And I definitely think Safari should have some of these! It's a bit cruel on them! Hahaha! :)
But very cool site. And I definitely think Safari should have some of these! It's a bit cruel on them! Hahaha! :)
so basically if an app can be ported as a web app, safari in ios won't support it? seems.....convenient
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.
Hypertext
For most of them it’s good that they are missing.
threeseed(3)
How iOS would support `::selection` with the tap-based interface?
Same for the CSS3 Cursor properties, doesn't make much sense on a touch-based device.
iOS still supports selection, and as such it is not unreasonable to desire the ability to style it, or react to it.
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.
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…
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…
You're saying some of the 404s should be 400s.
Cute. Some of these are already/soon out of date. Safari Technology Preview just shipped View Transisitions API https://webkit.org/blog/15260/release-notes-for-safari-techn...
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.
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 copying is a good point.
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.
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.
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.
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.
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.
You sent me down a rabbit hole. Wikipedia got us covered: https://en.wikipedia.org/wiki/Missing-children_milk_carton
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.
It’s amazing something so short-lived had such an impact.
The one browser API I wish every browser would support is the File System Access API.
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.
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.
You can check why Mozilla and Apple have opted to not support this.
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.
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.
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.
> 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.
Safari already supports a permission-less file system API with a very similar security model to iOS's filesystem access.
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.
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.
Your parent comment point still valid.
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...
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...
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.
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.
Yup - As commented in 2021 a 'Save As' API was seen as reasonable by Mozilla. I'm not sure what progress has been on the proposal since then.
https://github.com/mozilla/standards-positions/issues/154#is...
https://github.com/mozilla/standards-positions/issues/154#is...
[deleted]
[deleted]
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.
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.
[deleted]
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