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

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

From: Ian Hickson <ian@hixie.ch>
Date: Tue, 1 Oct 2013 20:44:11 +0000 (UTC)
To: Jonas Sicking <jonas@sicking.cc>, Glenn Maynard <glenn@zewt.org>
Message-ID: <alpine.DEB.2.00.1310012041150.1460@ps20323.dreamhostps.com>
Cc: WHAT Working Group <whatwg@lists.whatwg.org>, Jonathan Watt <jwatt@jwatt.org>
On Thu, 29 Aug 2013, Jonas Sicking wrote:
> On Thu, Aug 29, 2013 at 2:45 PM, Ian Hickson <ian@hixie.ch> wrote:
> > On Thu, 29 Aug 2013, Jonas Sicking wrote:
> >> On Thu, Aug 29, 2013 at 1:20 PM, Ian Hickson <ian@hixie.ch> wrote:
> >> > On Fri, 2 Aug 2013, Jonathan Watt wrote:
> >> >>
> >> >> I'm working on Mozilla's implementation of <input type=file> to 
> >> >> allow the user to pick a directory. The idea would be that the 
> >> >> files in that directory and its subdirectories would be added to 
> >> >> the HTMLInputElement.files FileList.
> >> >
> >> > This seems to be dangerous in that it makes it really easy for the 
> >> > user to select a single item that expands into tens of thousands if 
> >> > not millions of files on a remote disk, which then all have to be 
> >> > synchronously enumerated to get the count so that code can then 
> >> > itself enumerate through the entire list.
> >>
> >> We don't have to do any enumeration synchronously. It can all happen 
> >> off the main thread. The .click() "API" is asynchronous.
> >
> > It's asynchronous to the JS, sure, but at the end of the day the user 
> > can't get any work done until it's complete. It's synchronous as far 
> > as the user is concerned.
> 
> Sure. The alternative is that the user attaches each file separately. 

That's not the only alternative. For example, a third alternative is that 
the user's selection (e.g. a directory) is returned quickly, not 
pre-expanded, and then any uploading happens in the background with the 
author script doing the walk and uploading the files.


> >> > So you wouldn't be able to pick a file and a directory as in the 
> >> > example above? That seems unfortunate...
> >>
> >> Unfortunately most OSs doesn't have support for filepickers that can 
> >> select either a file or a directory.
> >
> > True. From a UI perspective it's kind of weird that the user has to 
> > decide which he wants, though. Similarly, from an authoring 
> > perspective, I don't understand how I would decide whether to show a 
> > multiple file picker or a directory picker.
> 
> You display two buttons in the website UI, one for "pick file" and one 
> for "pick directory". We don't really have a choice as long as we live 
> under the two constraints of:
>
> * Websites wants to do their own "pick" UI
> * OSs can't display pickers which allow picking either a file or a directory.

I don't think I've ever seen a native application on any platform offer 
two buttons, one to pick one or more files, and one to pick one (or more?) 
directories. I think this should be a large red flag. Now if I'm wrong and 
this kind of UI is in fact a thing, then fair enough, but if it's not, 
maybe we should go and study how this problem is solved in native apps.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 1 October 2013 20:44:35 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:11 UTC