- From: ddailey <ddailey@zoominternet.net>
- Date: Fri, 11 Dec 2009 16:52:47 -0500
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" <jonas@sicking.cc> To: <ifette at google.com> Cc: "whatwg" <whatwg at whatwg.org> Sent: Friday, December 11, 2009 12:29 AM Subject: Re: [whatwg] Uploading directories of files > 2009/12/10 Ian Fette (????????) <ifette at 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 > >
Received on Friday, 11 December 2009 13:52:47 UTC