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

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

From: Jonas Sicking <jonas@sicking.cc>
Date: Sun, 4 Aug 2013 00:47:34 -0700
Message-ID: <CA+c2ei-AX50UjRHLSBo-WDtyUHpbf7SGQtczURpyF_gg=OPV8Q@mail.gmail.com>
To: Glenn Maynard <glenn@zewt.org>
Cc: whatwg <whatwg@lists.whatwg.org>, Jonathan Watt <jwatt@jwatt.org>
On Fri, Aug 2, 2013 at 3:39 PM, Glenn Maynard <glenn@zewt.org> wrote:
> On Fri, Aug 2, 2013 at 11:15 AM, Jonathan Watt <jwatt@jwatt.org> wrote:
>> In my prototype implementation it took around 30 seconds to build the
>> FileList for a directory of 200,000 files with a top end SSD; so depending
>> on what the page is doing, directory picking could take some time.
> A static list isn't appropriate for recursively exposing a large
> directory.  I hope that won't be implemented, since that's the sort of
> halfway-feature--"not quite good enough, but it sort of works"--that can
> delay a good API indefinitely.  An interface to allow scripts to navigate
> the tree like a filesystem should be used, to avoid having to do a full
> recursion.
> For example, a photo browser probably only wants to read data on demand, as
> the user navigates.  Also, doing it synchronously means that if the user
> adds another photo, he'd have to reopen the directory (and wait for the
> long recursion) all over again for it to be seen by the app.
> A previous discussion (on drag and drop, but the issues are the same) is
> here:
> http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-November/033814.html
> That centered around FS-API, which is probably not the direction things are
> going, but whichever API things land on for filesystem access should
> probably be used for this--or vice-versa, if this comes first.  I suspect
> they're actually the same thing, since a file picker (along with drag and
> drop) is the likely way to expose a filesystem-of-real-files API.

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.

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.

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

/ Jonas
Received on Sunday, 4 August 2013 07:48:28 UTC

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