W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2013

Re: [whatwg] Forms: <input type=file> and directory tree picking

From: Jonathan Watt <jwatt@jwatt.org>
Date: Mon, 05 Aug 2013 17:18:41 +0100
Message-ID: <51FFD061.9060604@jwatt.org>
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

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:23 UTC