- From: Jonathan Watt <jwatt@jwatt.org>
- Date: Mon, 05 Aug 2013 17:18:41 +0100
- To: Glenn Maynard <glenn@zewt.org>
- Cc: whatwg <whatwg@lists.whatwg.org>, Jonas Sicking <jonas@sicking.cc>
On 05/08/2013 00:54, Glenn Maynard wrote: > On Sun, Aug 4, 2013 at 2:47 AM, Jonas Sicking <jonas@sicking.cc> wrote: > >> We can't do what you are suggesting for a plain <input type=file >> multiple> since there's already a defined API for that, and that API >> only exposes a .files property in the DOM. >> > > Sure we can; we can always add to that API, such as adding a > getFileSystem() method. A different @type may be better anyway, though. Currently my own view is that exposing a filesystem type API must be opt-in (as in new code has to be written to use it; old code isn't going to "just work"). As such a new attribute [value] such as multiple=fs could be required to make use of it, and could change the behavior of the input so that it doesn't build up a FileList, but instead sets .files to an object representing the picked directory if a directory is picked. -Jonathan > But we could certainly add some way to enable creating an <input> >> which exposes files and directories in the DOM, rather than just >> files. Doing that will depend on coming up with a filesystem proposal >> which all parties actually agree on implementing, so far we don't have >> such a proposal. >> > > Unless we think it won't ever happen, it'd be better to keep working > towards that than to rush things and implement greedy recursion. > > It also requires an actual proposal for what such an <input> would >> look like. I.e. would it be an <input type=file directory>? Or <input >> type=file multiple> with some sort of API call saying that flattening >> directories into files aren't needed? Or <input >> type=filesanddirectories>? >> > > It's probably not worth worrying about this part too much until we have a > filesystem API for it to enable. Any of these seem fine (though I'd lean > away from an API call), or maybe <input type=file multiple=fs>, which would > cause it to fall back on the current (files only, non-recursive FileList) > behavior on browsers that don't support it. > > (I don't think "flattening directories into files" is something that should > ever happen in the first place, but if it does we'd definitely need to make > sure it doesn't happen in this mode.) >
Received on Monday, 5 August 2013 16:19:11 UTC