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.
