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

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

From: Ojan Vafai <ojan@chromium.org>
Date: Wed, 12 May 2010 08:33:15 -0700
Message-ID: <w2u78dc8441005120833y3da038e4k479e355cead9199c@mail.gmail.com>
On Wed, May 12, 2010 at 4:39 AM, Anne van Kesteren <annevk at opera.com> wrote:

> On Sat, 24 Apr 2010 17:58:10 +0200, Ojan Vafai <ojan at chromium.org> wrote:
>
>> 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?
>

Correct. We should try to solve that problem. I was just voicing my distaste
for the solution to that problem being adding a new input type that
exclusively works on directories.

So far, the best solution I've heard is adding partial path information
(e.g. a "paths" property that parallels the "files" property). That has it's
short-comings as well, but it works for the majority of use-cases.

Ojan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100512/6fb5eb59/attachment.htm>
Received on Wednesday, 12 May 2010 08:33:15 UTC

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