W3C home > Mailing lists > Public > whatwg@whatwg.org > December 2009

[whatwg] Uploading directories of files

From: Ian Fette <ifette@google.com>
Date: Sun, 13 Dec 2009 15:54:17 -0800
Message-ID: <bbeaa26f0912131554m3b317f33l4662fd82c131f39d@mail.gmail.com>
2009/12/11 Anne van Kesteren <annevk at opera.com>

> On Fri, 11 Dec 2009 15:24:37 +0100, Ian Fette (????????) <
> ifette at google.com> wrote:
>
>> Ok, I sense resistance to putting it in .name. What about .path, undefined
>> in most cases except where there is an upload including files from
>> multiple
>> directories, in which case .path contains the path less any path
>> components
>> common to all 3 (sorry, it's early morning and I can't write well before
>> having coffee).
>>
>> e.g.
>>
>> input.files[0].name="1.jpg"
>> input.files[0].path="a/b"
>> input.files[1].name="2.jpg"
>> input.files[1].path="a/b"
>> input.files[2].name="3.jpg"
>> input.files[2].path="a/c"
>>
>> (Need to figure out the exact wording, as "a" is common to all 3 but if
>> you're uploading the entire directory "a", it may make sense to include
>> that
>> in the path -- but I don't feel quite as strongly about that -- subfolders
>> are certainly more important IMO.)
>>
>
> Note that extensions to File should be discussed on public-webapps at w3.org.
> At least, that's where they have been so far.
>
>
>
Anne -- happy to move the File related discussion to public-webapps at . For
the sake of wrapping up this thread though, are there there any changes that
would need to be made to the HTML spec to allow this behavior (including
limited path information in the name that gets sent when the form is
posted?) I can't seem to find the actual part of the spec that defines or
restricts what characters are valid in context.


>
> --
> Anne van Kesteren
> http://annevankesteren.nl/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091213/902d9cc5/attachment.htm>
Received on Sunday, 13 December 2009 15:54:17 UTC

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