- From: Glenn Maynard <glenn@zewt.org>
- Date: Sun, 4 Aug 2013 18:54:51 -0500
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: whatwg <whatwg@lists.whatwg.org>, Jonathan Watt <jwatt@jwatt.org>
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. 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.) -- Glenn Maynard
Received on Sunday, 4 August 2013 23:55:17 UTC