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