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

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

From: Glenn Maynard <glenn@zewt.org>
Date: Fri, 2 Aug 2013 17:39:13 -0500
Message-ID: <CABirCh8K2V9+U5eQ6SW5WYYAJvwDOGsk0sGBzG7OjGcE5mjQsw@mail.gmail.com>
To: Jonathan Watt <jwatt@jwatt.org>
Cc: whatwg <whatwg@lists.whatwg.org>
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

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


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.

Glenn Maynard
Received on Friday, 2 August 2013 22:39:40 UTC

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