Re: [whatwg] Make the files attribute of the input element writable
On 07/12/12 21:42, Victor Costan wrote: On Wed, Dec 5, 2012 at 12:11 PM, Ian Hickson i...@hixie.ch wrote: On Wed, 5 Dec 2012, Victor Costan wrote: There was a thread on this mailing list discussing making it possible to set the file data behind an input type=file element. http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-May/thread.html#36140 The thread seems to have died down due to insufficient applications for the proposal. Actually the reason this thread hasn't gone anywhere is that there seems to only be implementer interest from Chrome. See: http://wiki.whatwg.org/wiki/New_Features_Awaiting_Implementation_Interest Thank you very much for explaining! I can file a bug against Firefox, and argue for it. I think I would have an easier time making an argument if I knew how the API should look like. Can you please give me a hint as to which variant you'd be more likely to agree with? Mutable FileLists vs a way to put together a new FileList + writable files attribute on input type=file? File constructor taking a Blob + name vs having Blobs in a FileList? There is already a bug for it: https://bugzilla.mozilla.org/show_bug.cgi?id=757664 -- Mounir
Re: [whatwg] Make the files attribute of the input element writable
On 1/17/13, Ian Hickson i...@hixie.ch wrote: On Fri, 7 Dec 2012, Victor Costan wrote: On Wed, Dec 5, 2012 at 12:11 PM, Ian Hickson i...@hixie.ch wrote: On Wed, 5 Dec 2012, Victor Costan wrote: There was a thread on this mailing list discussing making it possible to set the file data behind an input type=file element. http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-May/thread.html#36140 The thread seems to have died down due to insufficient applications for the proposal. Actually the reason this thread hasn't gone anywhere is that there seems to only be implementer interest from Chrome. See: http://wiki.whatwg.org/wiki/New_Features_Awaiting_Implementation_Interest Thank you very much for explaining! I can file a bug against Firefox, and argue for it. I think I would have an easier time making an argument if I knew how the API should look like. Can you please give me a hint as to which variant you'd be more likely to agree with? Whatever browsers are willing to implement, basically. 1) This would make it possible to write JavaScript libraries that seamlessly scan the current page for input type=file and add integration with Dropbox / Google Drive / Sky Drive etc. I claim that changing the input value is the easiest and most robust method of achieving this without requiring changes to the main application code. Asides from providing an easy path for developers to integrate online storage services into their apps, this change would make it easy to write bookmarklets / browser extensions that add this functionality to any Web application. It seems like this use case would be better handled by having the sites offer an API to the browser, similar to Web Intents, for picking a file. That way you wouldn't need to update each site -- every site would support all the drive systems you use. Yes, but that approach would require deeper application changes. I think that adding a couple of script tags next to an existing input type=file is easier to implement. On the one hand, we require every application that can read a file to modify their code to support the drive providers, and we require the drive providers to provide code to support this, and we need UA changes, and we make it hard to competitors of drive-like products to compete (since anyone popular enough to be included by the sites that support this will have a network effect advantage). On the other hand, we require only drive providers and user agents to write code, and every site that reads files supports every provider that implements the API, and there's no barrier to entry for competitors. I think the second is _significantly_ better all around. But there are other use cases (such as the ones you listed) for which it makes sense to be able to add files to input type=file. There are places where FileList definitely needs to be readonly, so I don't think it makes sense to make it globally writable. but there could be a MutableFileList or something. That feedback should be sent to the list mentioned at the top of the File API spec. FileList doesn't have to be mutable if there is a FileList constructor that accepts File instances, or if the files attribute of input type=file accepts an array of File instances and converts it into a FileList. Indeed, both of those solutions would work too. There could also be a method on HTMLInputElement to push files into .files, or to clear .files, or some such. The file input's value, as useless as it is, should stay in sync with the fileList. Any method to clear the files must also reset the input's value to . . A few ideas: fileInp.value = ; // change an old property's behavior fileInp.files.length = 0; // changes a recent property's behavior fileInp.reset(); // old method name on new object fileInp.clear(); // new method name, new behavior (no conflict). -- Garrett Twitter: @xkit personx.tumblr.com
Re: [whatwg] Make the files attribute of the input element writable
Date: Thu, 17 Jan 2013 20:45:59 + From: i...@hixie.ch ... 1) This would make it possible to write JavaScript libraries that seamlessly scan the current page for input type=file and add integration with Dropbox / Google Drive / Sky Drive etc. I claim that changing the input value is the easiest and most robust method of achieving this without requiring changes to the main application code. Asides from providing an easy path for developers to integrate online storage services into their apps, this change would make it easy to write bookmarklets / browser extensions that add this functionality to any Web application. It seems like this use case would be better handled by having the sites offer an API to the browser, similar to Web Intents, for picking a file. That way you wouldn't need to update each site -- every site would support all the drive systems you use. Yes, but that approach would require deeper application changes. I think that adding a couple of script tags next to an existing input type=file is easier to implement. On the one hand, we require every application that can read a file to modify their code to support the drive providers, and we require the drive providers to provide code to support this, and we need UA changes, and we make it hard to competitors of drive-like products to compete (since anyone popular enough to be included by the sites that support this will have a network effect advantage). On the other hand, we require only drive providers and user agents to write code, and every site that reads files supports every provider that implements the API, and there's no barrier to entry for competitors. I think the second is _significantly_ better all around. FWIW The second solution, of a 'web intents' style mechanism, might also help users secure their data by allowing them to use trusted apps and to even take advantage of 'drive' providers when Javascript is disabled. The benefits might also be applicable to other input types, and how this might be done is something I am exploring for the PUA CG: http://lists.w3.org/Archives/Public/public-pua/2013Jan/.html It would be useful for the browser to store the returned blob to allow serial invocation of web intents before the final blob is submitted. For example, a user might source a file in from a camera then invoke a number of processing apps before the image is submitted. It would be useful to support other input element types, such as text boxes. For example, rich editors for HTML or Wikimedia could be handled by apps and the content returned to the input element. It would be useful to support general multi-input and multi-output to input elements for each web intents invocation. For example consider an input form with a delivery address - the user might use web intents to search for a contact using a web app that accepts any already supplied inputs and returns the required fields to fill the form elements. Declarative markup would allow this to work even within a page with Javascript disabled or restricted, and the infrastructure might help browsers offer invocation suggestions even when a webpage does not have declarative support. For example, if a user has chosen a rich Wikimedia editor for textbox input on a particular web page then the browser might make this an easier choice in future. Such support would give the user more choice in the apps used for common tasks within web pages. It might gain support from businesses wanting to market their own web apps as substitutes, while allowing security conscience users to choose trusted apps. It might negatively impact businesses that gain from bundling the implementations of these tasks and restricting user choice, but perhaps on the balance it might be possible to win support given that there is some support for 'web intents' style solutions. cheers Fred
Re: [whatwg] Make the files attribute of the input element writable
On Fri, 7 Dec 2012, Victor Costan wrote: On Wed, Dec 5, 2012 at 12:11 PM, Ian Hickson i...@hixie.ch wrote: On Wed, 5 Dec 2012, Victor Costan wrote: There was a thread on this mailing list discussing making it possible to set the file data behind an input type=file element. http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-May/thread.html#36140 The thread seems to have died down due to insufficient applications for the proposal. Actually the reason this thread hasn't gone anywhere is that there seems to only be implementer interest from Chrome. See: http://wiki.whatwg.org/wiki/New_Features_Awaiting_Implementation_Interest Thank you very much for explaining! I can file a bug against Firefox, and argue for it. I think I would have an easier time making an argument if I knew how the API should look like. Can you please give me a hint as to which variant you'd be more likely to agree with? Whatever browsers are willing to implement, basically. 1) This would make it possible to write JavaScript libraries that seamlessly scan the current page for input type=file and add integration with Dropbox / Google Drive / Sky Drive etc. I claim that changing the input value is the easiest and most robust method of achieving this without requiring changes to the main application code. Asides from providing an easy path for developers to integrate online storage services into their apps, this change would make it easy to write bookmarklets / browser extensions that add this functionality to any Web application. It seems like this use case would be better handled by having the sites offer an API to the browser, similar to Web Intents, for picking a file. That way you wouldn't need to update each site -- every site would support all the drive systems you use. Yes, but that approach would require deeper application changes. I think that adding a couple of script tags next to an existing input type=file is easier to implement. On the one hand, we require every application that can read a file to modify their code to support the drive providers, and we require the drive providers to provide code to support this, and we need UA changes, and we make it hard to competitors of drive-like products to compete (since anyone popular enough to be included by the sites that support this will have a network effect advantage). On the other hand, we require only drive providers and user agents to write code, and every site that reads files supports every provider that implements the API, and there's no barrier to entry for competitors. I think the second is _significantly_ better all around. But there are other use cases (such as the ones you listed) for which it makes sense to be able to add files to input type=file. There are places where FileList definitely needs to be readonly, so I don't think it makes sense to make it globally writable. but there could be a MutableFileList or something. That feedback should be sent to the list mentioned at the top of the File API spec. FileList doesn't have to be mutable if there is a FileList constructor that accepts File instances, or if the files attribute of input type=file accepts an array of File instances and converts it into a FileList. Indeed, both of those solutions would work too. There could also be a method on HTMLInputElement to push files into .files, or to clear .files, or some such. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Make the files attribute of the input element writable
On Wed, Dec 5, 2012 at 9:11 AM, Ian Hickson i...@hixie.ch wrote: On Wed, 5 Dec 2012, Victor Costan wrote: There was a thread on this mailing list discussing making it possible to set the file data behind an input type=file element. http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-May/thread.html#36140 The thread seems to have died down due to insufficient applications for the proposal. Actually the reason this thread hasn't gone anywhere is that there seems to only be implementer interest from Chrome. Actually, I'd be quite interested to see this implemented in Gecko. My only requirement is that something like the following should work: myFileInput.files = [ablob, afile, anotherblob, new Blob([foo])]; / Jonas
Re: [whatwg] Make the files attribute of the input element writable
On 12/15/12 8:39 PM, Jonas Sicking wrote: myFileInput.files = [ablob, afile, anotherblob, new Blob([foo])]; There's no way to express that in WebIDL, but I think that's a bug we should fix in WebIDL. We should allow getters and setters for attributes to accept different IDL types... -Boris
Re: [whatwg] Make the files attribute of the input element writable
On 16/12/12 2:05 PM, Boris Zbarsky wrote: There's no way to express that in WebIDL, but I think that's a bug we should fix in WebIDL. We should allow getters and setters for attributes to accept different IDL types... Yeah, that has come up a couple of times now. Filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=20407.
Re: [whatwg] Make the files attribute of the input element writable
On Wed, Dec 5, 2012 at 12:11 PM, Ian Hickson i...@hixie.ch wrote: On Wed, 5 Dec 2012, Victor Costan wrote: There was a thread on this mailing list discussing making it possible to set the file data behind an input type=file element. http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-May/thread.html#36140 The thread seems to have died down due to insufficient applications for the proposal. Actually the reason this thread hasn't gone anywhere is that there seems to only be implementer interest from Chrome. See: http://wiki.whatwg.org/wiki/New_Features_Awaiting_Implementation_Interest Thank you very much for explaining! I can file a bug against Firefox, and argue for it. I think I would have an easier time making an argument if I knew how the API should look like. Can you please give me a hint as to which variant you'd be more likely to agree with? Mutable FileLists vs a way to put together a new FileList + writable files attribute on input type=file? File constructor taking a Blob + name vs having Blobs in a FileList? 1) This would make it possible to write JavaScript libraries that seamlessly scan the current page for input type=file and add integration with Dropbox / Google Drive / Sky Drive etc. I claim that changing the input value is the easiest and most robust method of achieving this without requiring changes to the main application code. Asides from providing an easy path for developers to integrate online storage services into their apps, this change would make it easy to write bookmarklets / browser extensions that add this functionality to any Web application. It seems like this use case would be better handled by having the sites offer an API to the browser, similar to Web Intents, for picking a file. That way you wouldn't need to update each site -- every site would support all the drive systems you use. Yes, but that approach would require deeper application changes. I think that adding a couple of script tags next to an existing input type=file is easier to implement. 2) If I can set the files attribute of an input type=file, I can write unit tests for any code that deals with such an input, such as XHR uploads. Tested code is less likely to break down as it is maintained, so it makes for a better Web. That's an interesting use case, indeed. Thank you! In general, read-only APIs make testing really hard :( 3) Browser extensions / bookmarklets could easily filter files being uploaded. For example, an extension could automatically resize pictures larger than a certain threshold by rendering them to an off-screen canvas. As another example, an extension could detect when huge files are uploaded to a Web mail client or forum, automatically upload them to Dropbox / Google Drive / Sky Drive, and replace them in the input type=file with tiny .url files pointing to the real files. In general, browser extensions don't have to be handled by Web standard APIs, so I'm not sure that's a compelling use case. I think it would be useful to have a drop-in JS library that can perform image resizing on the fly without requiring XHR-based form submission. With these applications in mind, I don't think FileList needs to accept Blobs. Instead, there should be an easy way to build a File out of a Blob and a file name. This capability seems to have been lost when BlobBuilder was deprecated by the Blob constructor. There are places where FileList definitely needs to be readonly, so I don't think it makes sense to make it globally writable. but there could be a MutableFileList or something. That feedback should be sent to the list mentioned at the top of the File API spec. FileList doesn't have to be mutable if there is a FileList constructor that accepts File instances, or if the files attribute of input type=file accepts an array of File instances and converts it into a FileList. I will start a discussion on the public-weba...@w3.org. For reference, they seem to be in favor of a File constructor. http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/0692.html Thank you very much for your consideration, Victor
Re: [whatwg] Make the files attribute of the input element writable
On Wed, 5 Dec 2012, Victor Costan wrote: There was a thread on this mailing list discussing making it possible to set the file data behind an input type=file element. http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-May/thread.html#36140 The thread seems to have died down due to insufficient applications for the proposal. Actually the reason this thread hasn't gone anywhere is that there seems to only be implementer interest from Chrome. See: http://wiki.whatwg.org/wiki/New_Features_Awaiting_Implementation_Interest 1) This would make it possible to write JavaScript libraries that seamlessly scan the current page for input type=file and add integration with Dropbox / Google Drive / Sky Drive etc. I claim that changing the input value is the easiest and most robust method of achieving this without requiring changes to the main application code. Asides from providing an easy path for developers to integrate online storage services into their apps, this change would make it easy to write bookmarklets / browser extensions that add this functionality to any Web application. It seems like this use case would be better handled by having the sites offer an API to the browser, similar to Web Intents, for picking a file. That way you wouldn't need to update each site -- every site would support all the drive systems you use. 2) If I can set the files attribute of an input type=file, I can write unit tests for any code that deals with such an input, such as XHR uploads. Tested code is less likely to break down as it is maintained, so it makes for a better Web. That's an interesting use case, indeed. 3) Browser extensions / bookmarklets could easily filter files being uploaded. For example, an extension could automatically resize pictures larger than a certain threshold by rendering them to an off-screen canvas. As another example, an extension could detect when huge files are uploaded to a Web mail client or forum, automatically upload them to Dropbox / Google Drive / Sky Drive, and replace them in the input type=file with tiny .url files pointing to the real files. In general, browser extensions don't have to be handled by Web standard APIs, so I'm not sure that's a compelling use case. With these applications in mind, I don't think FileList needs to accept Blobs. Instead, there should be an easy way to build a File out of a Blob and a file name. This capability seems to have been lost when BlobBuilder was deprecated by the Blob constructor. There are places where FileList definitely needs to be readonly, so I don't think it makes sense to make it globally writable. but there could be a MutableFileList or something. That feedback should be sent to the list mentioned at the top of the File API spec. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
