This thread (of which some especially salient points are included below)
requested the addition of a feature or the codifying of a convention for
uploading directory tree structures in input type=file.
I think that including relative directory paths with uploads is a quite
reasonable feature.
On Friday 2009-12-11 02:17 -0800, Jeremy Orlow wrote:
But regardless.I don't think you could argue that having _some_ path
information is worse than _none_, right?
Many of those who commented in
https://bugzilla.mozilla.org/show_bug.cgi?id=143220 and its
duplicates would disagree. Users
-
From: L. David Baron dba...@dbaron.org
To: Jeremy Orlow jor...@chromium.org
Cc: Markus Ernst derer...@gmx.ch; whatwg wha...@whatwg.org
Sent: Sunday, December 13, 2009 3:01 AM
Subject: Re: [whatwg] Uploading directories of files
On Friday 2009-12-11 02:17 -0800, Jeremy Orlow wrote
2009/12/11 Anne van Kesteren ann...@opera.com
On Fri, 11 Dec 2009 15:24:37 +0100, Ian Fette (イアンフェッティ)
ife...@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
2009/12/13 Ian Fette (イアンフェッティ) ife...@google.com:
2009/12/11 Anne van Kesteren ann...@opera.com
On Fri, 11 Dec 2009 15:24:37 +0100, Ian Fette (イアンフェッティ)
ife...@google.com wrote:
Ok, I sense resistance to putting it in .name. What about .path,
undefined
in most cases except where there is
Ian Fette (イアンフェッティ) schrieb:
I would think it preferable if
.name also were allowed to contain that extra information -- currently
we say The name of the file. There are numerous file name variations on
different systems; this is merely the name of the file, without path
information. [1]. I
On Fri, 11 Dec 2009 09:13:52 +0100, Markus Ernst derer...@gmx.ch wrote:
I have no idea how to handle such inconsistent behaviour on the server
side (except adding extra code to flatten all uploaded directory
structures before handling). I assume that HTTP upload should be kept
simple, and
Anne van Kesteren schrieb:
On Fri, 11 Dec 2009 09:13:52 +0100, Markus Ernst derer...@gmx.ch wrote:
I have no idea how to handle such inconsistent behaviour on the server
side (except adding extra code to flatten all uploaded directory
structures before handling). I assume that HTTP upload
On Fri, Dec 11, 2009 at 12:47 AM, Anne van Kesteren ann...@opera.comwrote:
On Fri, 11 Dec 2009 09:33:06 +0100, Markus Ernst derer...@gmx.ch wrote:
Anne van Kesteren schrieb:
On Fri, 11 Dec 2009 09:13:52 +0100, Markus Ernst derer...@gmx.ch
wrote:
I have no idea how to handle such
Anne van Kesteren schrieb:
On Fri, 11 Dec 2009 09:33:06 +0100, Markus Ernst derer...@gmx.ch wrote:
Anne van Kesteren schrieb:
On Fri, 11 Dec 2009 09:13:52 +0100, Markus Ernst derer...@gmx.ch
wrote:
I have no idea how to handle such inconsistent behaviour on the
server side (except adding
Jeremy Orlow schrieb:
On Fri, Dec 11, 2009 at 12:47 AM, Anne van Kesteren ann...@opera.com
And I mean that if it is important to application developers we
should make it available as a feature and not endorse some plug-in
dependency.
I (and I think most of us) strongly agree.
On Fri, Dec 11, 2009 at 2:30 AM, Markus Ernst derer...@gmx.ch wrote:
Jeremy Orlow schrieb:
On Fri, Dec 11, 2009 at 12:47 AM, Anne van Kesteren ann...@opera.com
And I mean that if it is important to application developers we
should make it available as a feature and not endorse some
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
On Fri, 11 Dec 2009 15:24:37 +0100, Ian Fette (イアンフェッティ)
ife...@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
Hi Ian,
thanks for suggesting recursive directory selection! This comes almost a bit
surprising to me, since Gears decided to deny this feature (
http://code.google.com/p/gears/wiki/FileSystemAPI). One of the reasons for
the denial still applies: how can the user be sure what he is uploading? If
2009/12/11 Ian Fette (イアンフェッティ) ife...@google.com
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
2009/12/11 ddailey ddai...@zoominternet.net:
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
on Friday, December 11, 2009 6:11 PM
Jonas Sicking wrote:
I'm fairly certain that any of the major browser vendors would be
quite horrified if this worked today. I.e. if the page could just grab
arbitrary files from the users file system. Occasionally people store
private data there ;)
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
2009/12/10 Jonas Sicking jo...@sicking.cc
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
2009/12/10 Ian Fette (イアンフェッティ) ife...@google.com:
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.
I think that the notion of
21 matches
Mail list logo
