W3C home > Mailing lists > Public > whatwg@whatwg.org > May 2010

[whatwg] Directory upload via <input type="file" directory>

From: Anne van Kesteren <annevk@opera.com>
Date: Wed, 12 May 2010 13:39:33 +0200
Message-ID: <op.vclbz7wk64w2qv@annevk-t60>
On Sat, 24 Apr 2010 17:58:10 +0200, Ojan Vafai <ojan at chromium.org> wrote:
> On Fri, Apr 23, 2010 at 8:41 PM, Anne van Kesteren <annevk at opera.com>  
> wrote:
>> On Fri, 23 Apr 2010 07:11:08 +0900, Ojan Vafai <ojan at chromium.org>  
>> wrote:
>>> But there is already a default UI that lets you select a folder, a  
>>> file or both (drag-drop). I don't see why this forces the UA to do  
>>> anything. Just because you can select both folders and files doesn't  
>>> mean the UA needs to expose extra UI on top of drag-drop to let you do  
>>> so. Again, no more so than they already have to expose extra UI to  
>>> deal with multiple inputs.
>>
>> How does the drag & drop API support this use case?
>
> I'm not sure I understand the question. Are you suggesting that for cases
> where people want to support directory+file drops they should use  
> drag-drop instead of an input element?

I thought by drag-drop you meant the drag-and-drop API rather than a  
drag-drop operation on the <input type=file multiple> element.


> My point is more that input elements currently support dropping files  
> onto them in multiple browsers. It's confusing for "multiple" that  
> dropping
> directories+files doesn't upload said directories+files, or at least give
> some sort of indication to the user that some of them are being not  
> allowed.
>
> We should leave it up to UAs to figure out what the right UI should be,  
> but adding input "directory" seems to me like it will confuse the UI  
> more.
> Ideally users can drop whatever they want onto a file input that has
> "multiple" and it can be up to the web page to remove entries it doesn't
> allow. The web page is in a much better position to give user feedback  
> (e.g. a photo site can warn that only image uploads are allowed and that
> non-images won't get uploaded).

Even if we allow this we would still need to define the semantics. I.e.  
what the file names end up being, if the API supports hierarchical access,  
etc. Or am I missing something?


-- 
Anne van Kesteren
http://annevankesteren.nl/
Received on Wednesday, 12 May 2010 04:39:33 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:23 UTC