4 ms·

Browsers have been able to get access to files on disk for longer now than many Web developers have even had careers—drag and drop was one of the first HTML5 AP

by cxr 4y ago

Browsers have been able to get access to files on disk for longer now than many Web developers have even had careers—drag and drop was one of the first HTML5 APIs. Same with client-side processing for `<input type="file">` elements. (Directory access through the `webkitdirectory` attribute is another story, but it did eventually gain support from all major browsers—even if it's terribly named and the scary warnings about how it will "probably" go away on MDN haven't been updated.) As for writing, you don't get unlimited unchecked writes the way that Chrome's proposed Filesystem Access API grants you, but you can trigger "checked" writes (that show a file save dialog) using `<a/>` elements with the `download` attribute. This is arguably a better user experience, because it keeps the user in the loop, giving them the opportunity to veto (or rename/relocate) the written file—which will be difficult or impossible to do if the Chrome team's proposed API became standard. Overall, the File System Access proposal is a bad one that gets the developer vs user prioritization wrong (favoring the convenience and satisfaction of the former over preserving control for the latter), and I hope it doesn't become either a de facto or a de jure fixture of the Web platform soon. Here's to hoping for a future post to the Chrome Developers blog announcing that this is yet another experimental API of theirs that they have decided is going to be sunset in some future release.

nine_k 4y ago
This is not access to the filesystem. This is access to some controlled contents that happen to come from the filesystem, with interaction explicitly initiated by the user every time. It gives the browser no access to the structure of the filesystem, no way to navigate it, and crucially no way to transparently read or write anything. This is good isolation, I'd prefer it to be this way. OFS also gives equally good isolation, I'm fine with that. Sharing between OFS and the rest of the user's file system should be possible, but only explicitly, a la iOS, Android, and the file upload / download dialog.
- cxr 4y ago
  Please follow the discussion; we are not referring to the narrow "origin private file system" here. > This is not access to the filesystem. Wrong. I know what "this" is, thanks, and it is access to the filesystem. That's because "this" here—in the subthread you have just posted to—refers to Chrome's experimental implementation of the larger proposal (which is literally called "File System Access API"), not the limited subset described by the submission as having just gotten enabed in Firefox.
  - nine_k 4y ago
    Please take another look at the comment I was replying to. It was about <input type="file"> and <a> with disposition attribute, which are not filesystem access. While Google's new API definitely is.
    - cxr 4y ago
      > Please take another look at the comment I was replying to. It was about <input type="file"> and <a> with disposition attribute It's the `download` attribute, but yeah, I understand the significance of those words. I wrote them. Your replies in this thread, on the other hand, are confusing at best. What are you actually trying to communicate?

by cxr 4y ago

nine_k 4y ago

This is not access to the filesystem. This is access to some controlled contents that happen to come from the filesystem, with interaction explicitly initiated by the user every time. It gives the browser no access to the structure of the filesystem, no way to navigate it, and crucially no way to transparently read or write anything. This is good isolation, I'd prefer it to be this way. OFS also gives equally good isolation, I'm fine with that. Sharing between OFS and the rest of the user's file system should be possible, but only explicitly, a la iOS, Android, and the file upload / download dialog.

cxr 4y ago
Please follow the discussion; we are not referring to the narrow "origin private file system" here. > This is not access to the filesystem. Wrong. I know what "this" is, thanks, and it is access to the filesystem. That's because "this" here—in the subthread you have just posted to—refers to Chrome's experimental implementation of the larger proposal (which is literally called "File System Access API"), not the limited subset described by the submission as having just gotten enabed in Firefox.
- nine_k 4y ago
  Please take another look at the comment I was replying to. It was about <input type="file"> and <a> with disposition attribute, which are not filesystem access. While Google's new API definitely is.
  - cxr 4y ago
    > Please take another look at the comment I was replying to. It was about <input type="file"> and <a> with disposition attribute It's the `download` attribute, but yeah, I understand the significance of those words. I wrote them. Your replies in this thread, on the other hand, are confusing at best. What are you actually trying to communicate?