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

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

From: Ojan Vafai <ojan@chromium.org>
Date: Sat, 24 Apr 2010 08:58:10 -0700
Message-ID: <k2p78dc8441004240858x95b5006ax1f69d8174b4f2896@mail.gmail.com>
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?

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).

Ojan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100424/df944f52/attachment.htm>
Received on Saturday, 24 April 2010 08:58:10 UTC

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