- From: Ian Hickson <ian@hixie.ch>
- Date: Thu, 6 Aug 2009 23:43:39 +0000 (UTC)
With Arun's announcement of a stable File API spec [1], I have now updated HTML5 to handle the use cases listed below. [1] http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.html On Thu, 22 Jun 2006, ivan vadovic wrote: > > Is there any advanced DOM API planned for file upload? For example, how > can a script find out how many files is the user about to submit? I've just added input.files to handle this case. On Mon, 2 Oct 2006, Gervase Markham wrote: > Alex Vincent wrote: > > Allowing remote values in the file upload control could be a > > performance hit via networking, since we'd have to verify the file > > exists before saying valueMissing is false... > > Another option would be to say that for file upload controls, this > value/event is a) asynchronous and b) optional for user agents. > (Optional also meaning they could fire it for some paths and not > others.) In this case, behaviour would revert to the WF 1.0 behaviour. I think it is reasonable for a UA to only notice a selected file has disappeared in an asynchronous fashion. On Mon, 30 Apr 2007, Ian McKellar wrote: > On 4/25/07, David Hyatt <hyatt at apple.com> wrote: > > The use case of being able to drop images into a contenteditable > > region and have them show up as <img> elements at the appropriate > > place and then get automatically uploaded somewhere is a really > > compelling one. > > This is basically what we implemented in Flock. We also supported drag > and drop to text areas, though that's a little tricker since it's hard > for the user agent to work out how to embed images correctly. At the > basic level there's HTML vs BBCode syntax, beyond that different sites > filter different sets of tags and attributes in different fields (for > example on Flickr img tags are allowed in some fields in your profile > but not in others). I've added dataTransfer.files to the drag-and-drop interface. I'm not sure how to expose the presence of data during the drag, though. On Thu, 3 May 2007, ddailey wrote: > > A. Am I correct in assuming that the "The min and max attributes apply > to file upload controls " will handle the use case I'm outlining here > (except for the file saving part)? I suppose that once the user > identifies a collection of files then we would use script to swap src > attributes of image tags which we could then drag around or swap or > delete or whatever, and that the drag'n'drop proposal would eliminate > lots and lots of script. The way it's ended up, if the author specifies <input type=file multiple>, the user can pick as many files as he desires from that one control. Also, the user can drag and drop files either directly onto an <input type=file> in which case it sets the file selection, or onto something that a script can then grab the files from. > B. The statements on security in the WHATWG spec including: "For > security reasons, only content that the user knows is not hostile should > ever be allowed to submit or fetch files specified by file URIs. " ... > would this allow or not my poor old broken mini-app to re-emerge from > the dead? Scripts can't access the local file system, no. On Fri, 21 Sep 2007, Dave Camp wrote: > > It'd be possible to extend this to avoid bringing these files into > memory. We'd just need globalStorage (or something like it) to > accept/return nsIDOMFile objects, and a way for XHR to send them. Rather than making Storage support only DOMString and File, I've made Storage just support the same kinds of structures that we can post through postMessage(): http://www.whatwg.org/specs/web-apps/current-work/#safe-passing-of-structured-data That includes File. I've explicitly excluded ImageData since it has a sync reading API and typically lots of data, and that would be a perf issue. On Wed, 14 Nov 2007, Michael A. Puls II wrote: > > For example, if I make the page: > > file://localhost/c:/Documents%20and%20Settings/user/Desktop/test.html > <input type="file" oninput="alert(this.value)"> > > and choose the file 'f:\audio\some file.ogg', I expect the alert to > show "file://localhost/f:/audio/some%20file.ogg". > > (There's no harm in that exact situation.) > > For browsers, I really expect options like: > > [file input script access] > Reveal full path for file input = no (default) | yes with warning | yes > Full path format for file input = native (default) | file URI > Quote full path for file input = yes (default) | no > > However, the spec can't say those things I think. All it can say is > that scripts should only have access to the file name (like Opera). I ended up doing what IE8 does here, which, while rather suboptimal in many ways, has the advantage of being compatible with a variety of pages that do stupid things with <input type=file> as well as being relatively secure in not exposing the path. I don't think it makes sense to have this be preference-based. On Thu, 20 Mar 2008, ddailey wrote: > > In the code which follows, both IE7, FF(2.0), and Safari(3.1) allow the > user to change the src attribute of an image based on her perusal of > local file space. Opera 9.5 doesn't seem to allow access to the path > data necessary for accomplishing this rollover effect, and I suspect > that may be how it is supposed to be according to emerging standards. > That is the situation when the HTML file is stored on localhost. > > If however, one places the code on a server (see > http://granite.sru.edu/~ddailey/imageUpload.htm) then the program works > from none of the browsers. apologies in advance if I made a mistake :( > > While I understand the possible risk of exposing a path name of the > local file system to script, the various use cases of allowing users to > access local images within HTML, the <canvas> tag and within <svg> all > seem self-evident to me. Is there some standard workaround to allow the > user to change the source of an image on a web page to one that is > locally stored? I used to have a dozen mini-apps that took advantage of > the ability to do this (they even used to work in Netscape 4 and IE 4), > but the programs have all broken in the past few years in all contexts > except IE -- (for example here > http://granite.sru.edu/~ddailey/svg/clipembed.html where the input > type=file script is remarkably simple). > > What seems odd to me is that the browsers (except Opera) all seem to > expose the path data to script, despite blocking the easy use of that > data. Maybe I'm missing something obvious. > > Apologies, also, if this issue has already been discussed -- my memory > seems never to have been what it should have been. This is now possible using the File API and the special scheme for accessing files anonymously. On Thu, 19 Jun 2008, Adele Peterson wrote: > > I'm looking at the Web Forms 2 specification for the multi-file upload > control that uses the min/max attributes. When multiple files are > selected, its unclear what the value attribute should contain. It could > contain just the first filename, or a comma separated list of all of the > filenames. I think it will be useful though to add something about this > in the specification for consistency. Fixed. (It returns the first filename.) On Sat, 21 Jun 2008, Matthew Paul Thomas wrote: > > A related issue, that Web Forms 2 also doesn't seem to address: Should > it be possible to select the same file multiple times in the same upload > control? (I can imagine use cases for selecting the same file in > different upload controls on the same page, but none come to mind for > the same file in the same upload control.) The spec doesn't preclude it, but it doesn't require that it be possible, either. This is more of a UI issue than something that affects interop, as far as I can tell. > If it should be possible, but a Web author wants to prevent it in a case > where only distinct files make sense, should they be able to do so? And > if so, how? Relying on the browser-provided filename wouldn't be > reliable when that doesn't include the path. I expect when "only distinct files make sense" that it's more the contents that are the concern, not the source on the filesystem. (e.g. why would the same file twice be a problem but the same file twice via different hardlinks not be?) On Sun, 22 Jun 2008, Michael A. Puls II wrote: > > If the control is not long enough, you might not see the filename unless > you scroll in the field or the script resizes based on a multiple of the > length of .value. Even then, the path might be considered noise. > > An author might provide the filenames in a more friendly and readable > way. > > As another example, imagine you have <input type="file"> and onchange, > it adds a filename to a SELECT element and resizes the element. > > Then, the select has an onchange listener itself. When you select a > different file in the SELECT, you can make something happen. > > For example, you can browse to .wav files and add them to a select > playlist. Then, you can select each of the filenames to have them play > with Audio() for example. Attached is a super basic example of that. > > Instead of Audio(), you might load theora videos and play them with the > VideoLan plugin or load wmv files and play them with WMP. All these use cases are now handled by .files. On Wed, 10 Jun 2009, Adam Barth wrote: > > Currently the <input> element exposes selected files via a "files" > accessor (i.e., as in https://developer.mozilla.org/En/NsIDOMFileList > and http://www.w3.org/TR/file-upload/). We should add a similar > accessor to event.dataTransfer to enable drag-and-drop of files onto web > pages. Done, as mentioned above. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 6 August 2009 16:43:39 UTC