- From: Bronislav Klučka <Bronislav.Klucka@bauglir.com>
- Date: Wed, 23 May 2012 18:08:49 +0200
- To: whatwg@lists.whatwg.org
On 23.5.2012 17:37, Nico Weber wrote: >> But, by the same token, XHR upload of FormData[1] already serves this use case in a more flexible way. You can even make a FormData from the contents of an html form and then add additional File objects. Making the change would (afaict) not serve any new use cases. At most it would be a convenience. > Agreed, it's a convenience, the same could be do with a sync XHR > followed by a location.reload(). The readonly restriction exists for > historical reasons, and dropping it seems like a small change that > makes the web platform more usable. > > Nico Actually not that small.... if you have some form with files that you can either pick from <input file> or D&D those files somewhere, now, while constructong FormData/XHR you have to get the form data and check for any other places, where some files could have been dropped. Making FileList writable would mean that you can add file to <input file> and FormData/XHR usage is not just only more simple (all you need is to listen to drop event and solve it), but also better form theoretical programming point of view (why on earch a method to send form to server should know about what another UI belong to that form, sure, you can create the FormData and then pass it to that generic function, but it would require that the functionality to process form must know about anything else on that page, etc.) This would allow better modularization (I can just append a box to D&D files, programm this box to pass files to form and leave the original functionality as it is... etc.) B.
Received on Wednesday, 23 May 2012 16:09:43 UTC