Circa 1999 I built a little thingy: a client-side animation studio. It
allowed users to point to an image file in local file space. Then I would
preload the file, parse the path name and go looking for images with
consecutively numbered filenames in the same directory by attempting a
preload and checking the status of that -- hence allowing me to "upload" to
the local machine a series. Once the sequences had been identified and
loaded into the client-side app, the user then rearranged the sequence via
GUI to create the perfect animation which was then bundled as the source of
a new web page, complete with javascript and timing variables. It allowed
the GUI calibration of all such parameters. It was pretty cool (and
intensely useful for my students), but I realized as I was building it that
being able to troll through a user's filenames was a bit of a security risk,
since I could have shipped the files somewhere without the user's
permission. I even recall asking some browser gurus about it, but they
seemed largely unconcerned at the time. The miniapp worked in Netscape and
IE (with a little tweaking).
Some years later it stopped working everywhere, and I discovered to my
horror that the nasty "standards" folks had disabled client-side image
processing altogether, requiring instead that users send all their images to
my server for them to be able to even see their own files in the browser --
ahh progress! And all in the name of privacy! How charming.
I really do think that client-side image processing is a useful thing: hence
folks development of VML, SVG, Silverlight and Canvas. Allowing us to access
our pictures in a browser app does make sense if there is some way to enable
it.
cheers
David
----- Original Message -----
From: "Jonas Sicking" <jo...@sicking.cc>
To: <ife...@google.com>
Cc: "whatwg" <wha...@whatwg.org>
Sent: Friday, December 11, 2009 12:29 AM
Subject: Re: [whatwg] Uploading directories of files
2009/12/10 Ian Fette (イアンフェッティ) <ife...@google.com>:
USE CASE:
Many sites allow you to upload multiple files, often images. HTML5 allows
this via <input type="file" multiple>. This works well when your files
are
all in one folder, but it may often be the case that files are spread
across
sub-folders, and in this case you have to do multiple transactions (or
multiple <input type=file multiple> tags, which is just awkward) to
upload
your files.
PROPOSAL: Allow a UA to recursively select and upload a directory of
files.
How the UA chooses to modify the file picker dialog is outside the scope
of
this spec, but for the sake of argument, assume that the UA lets you pick
a
folder and say "upload all". Allow the UA to upload the files in the
folder,
with the subdirectories included in the filename with a directory
separator.
E.g. assume I have:
C:\users\ian\a\b\1.jpg
C:\users\ian\a\b\2.jpg
C:\users\ian\a\c\3.jpg
If the user chooses "a", the UA should be allowed to send all three files
with filenames:
"a/b/1.jpg"
"a/b/2.jpg"
"a/c/3.jpg"
as it would for the existing <input type=file multiple> implementation,
with
the addition of the directories and path separators (not full path, just
the
directory the user chose and sub-paths.)
Thoughts?
I don't think there is anything in the spec preventing you from doing
this right now. The fact that only files in the same folder can be
selected is a limitation in the implementation, not a limitation in
the spec.
The spec does require that only the leaf name, without any paths, are
submitted. Is that a problem?
I guess I'd be ok with changing the spec to allow more of the path to
be exposed. However that would mean that there is a mismatch between
what name is submitted and what name you'd get from
input.files[n].name.
/ Jonas
