Merge "File and Directory Entries API" into HTML

[arunranga]

In order to enable Directory Upload via the HTMLInputElement, Mozilla and Microsoft propose a change: the addition of the getFilesAndDirectories() method, initially proposed in the WICG.

https://wicg.github.io/directory-upload/proposal.html#dom-htmlinputelement-getfilesanddirectories

This method is also defined in the FileSystem API, on the Directory object:

http://w3c.github.io/filesystem-api/#widl-Directory-getFilesAndDirectories-Promise-FileOrDirectorySequence

These provide asynchronous ways of navigating user-selected files and directories. This issue is to specify getFilesAndDirectories on the HTMLInputElement.

[domenic]

Should this also include specifying the rest of the methods in partial interface HTMLInputElement from that explainer?

There are a lot of issues with the explainer text right now (e.g. promise-returning methods returning null, or void-returning methods returning promises) but we could work that out in the course of a pull request review.

[arunranga]

@domenic: you're right. The issue as originally filed focuses only on getFilesAndDirectories() and not on the other additions. So, this issue should also include specifying the rest, namely:

partial interface HTMLInputElement {
attribute boolean directory;
readonly attribute boolean isFilesAndDirectoriesSupported;
Promise<sequence<(File or Directory)>> getFilesAndDirectories();
void chooseDirectory();
};

[domenic]

@arunranga are you willing to submit a PR for this, or is this a request for the editors to spec out these interfaces? (And presumably the content attribute directory too.)

[arunranga]

I'm happy to submit a PR, modulo a resolution of the procedural discussion at https://www.w3.org/Bugs/Public/show_bug.cgi?id=29154#c4 initiated by the MSFT folks.

[annevk]

What is the status here @arunranga?

[arunranga]

Update: we're still bashing out the final API in W3C/WICG/directory-upload, including notable signature and call structure changes.

[annevk]

@bakulf mentioned that one big problem is that serialization of form data now needs to be asynchronous. That reportedly has some major repercussions. Since folks are apparently implementing something or other in this space we should probably do something. It's rather irresponsible to let all those algorithms get out of sync.

[domenic]

This now seems to be being specced at https://wicg.github.io/entries-api/, with several sections noted by @inexorabletash as "this should be merged into HTML".

[inexorabletash]

The entries-api attempts to specify the directory upload types and behavior as already implemented and shipping in Chrome, and apparently coming soon in Edge as well per @aliams, to ease interoperable implementations. As noted in the Explainer, "it is also very explicitly not a goal of this document to preclude further exploration of this area with APIs by other specifications that may improve the usability of this functionality"

I don't know what any other browser vendors' plans are, but I'd venture it's a tad early to merge anything into HTML in this space until we've got more clarity, though.

[annevk]

So Mozilla is implementing, but that specification not documenting how it affects serialization, form submission, navigation, etc. is a problem as I indicated above.

[annevk]

@pwnall @inexorabletash I have a vague recollection of a discussion about finally formalizing webkitdirectory and friends and why that might not be a good idea as perhaps we can still get rid of it. Is that accurate and would you mind summarizing here? (Also if inaccurate. 😊)

[inexorabletash]

cc: @mkruisselbrink

I'd summarize previous discussions as something like: rather than standardizing this one, we should design a new API from scratch that doesn't have the negatives of this API - callbacks, synchronous directory traversal, etc - and then remove this one from the platform when we can.

From Chrome's perspective, we've pushed forward on a more forward-looking set of file APIs in https://github.com/WICG/file-system-access/ which includes integration into drag/drop, only asynchronous iteration of directories, streams/promises everywhere, etc. I think any future investment in this space would be based on that work.

Given that, it would leave what this spec covers as a redundant legacy API in the platform, which could be removed only when all browsers have shipped the new API and we've migrated sufficient deployed content off. Practically speaking, I'm skeptical of that happening in any reasonable timeframe.

(I don't know if the new FS API actually has full parity at the moment though... I don't think it covers HTML form integration at all i.e. webkitdirectory-equivalent behavior, but I'm not sure developers actually want that. But just drag/drop may be insufficient for accessibility?)

[annevk]

@inexorabletash @mkruisselbrink any update on this? Safari only exposes this on macOS at the moment, but we think at least webkitdirectory would be useful on iOS too. However, perhaps there's something we could do API-wise to nudge people in the right direction.

[inexorabletash]

Since it's been a few years, @annevk can you clarify what you mean by "this" i.e. what you would like to see here, both in terms of spec logistics and evolving the platform APIs? Are you thinking about just the issue as stated i.e. merging entries-api into HTML or File API, or the broader issue of trying to deprecate/remove entries-api in favor of File System, or identifying the gaps needed to FS to parity, or ... ?

Neither @mkruisselbrink or I are super active in this space recently, but we have opinions 😉 and can loop in others.

[annevk]

@inexorabletash I think in particular I'm interested in how soon deprecation might happen as perhaps we could help by only supporting select aspects on iOS. I guess if that is contingent on a File System-based replacement we're still relatively far away from that.

cc @pxlcoder