Re: [w3ctag/design-reviews] Files and Directory Entries API with webkit prefixes! (#215)

Re: `webkitdirectory` + `multiple`

Good point - that needs specifying somewhere. I'll file a bug. In Chrome, at least, `webkitdirectory` takes precedence over `multiple` and the latter is ignored if both are specified, so you can't select multiple directories. I have not tested what other browsers implemented.

Re: promises

Since the non-Chrome browsers implemented this API somewhat reluctantly due to market/interop pressure, with entirely reasonable skepticism that the API is an ideal basis for the future, there's also been reluctance to commit to extending it at all, versus possibly introducing a new parallel API design. This manifested, for example, as objections raised at TPAC to adding the non-prefixed `directory` attribute with the same behavior, holding out hope that it could give access to an improved API instead.

Obviously, per the examples, I'm a fan of promises. :) It would be straightforward to e.g. add the following:

* on `FileSystemEntry`
  * `Promise<FileSystemDirectoryEntry> parent();`
* on `FileSystemDirectoryEntry`
  * `Promise<FileSystemFileEntry> file(path);`
  * `Promise<FileSystemDirectoryEntry> directory(path);`
* on `FileSystemFileEntry`
  * `Promise<File> file()`

... and a way to get an [async iterator](https://github.com/tc39/proposal-async-iteration) for entries on `FileSystemDirectoryEntry`, e.g. `entries()`. 




-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/215#issuecomment-359054350

Received on Friday, 19 January 2018 18:45:52 UTC