- From: Jonas Sicking <jonas@sicking.cc>
- Date: Fri, 11 Oct 2013 10:34:01 -0700
- To: Domenic Denicola <domenic@domenicdenicola.com>
- Cc: Boris Zbarsky <bzbarsky@mit.edu>, "public-script-coord@w3.org" <public-script-coord@w3.org>
Bringing back an old thread since we're in the process of implementing. On Apr 18, 2013 4:21 AM, "Domenic Denicola" <domenic@domenicdenicola.com> wrote: > > From: Boris Zbarsky [mailto:bzbarsky@MIT.EDU] > > > On 4/17/13 9:58 PM, Domenic Denicola wrote: > > > That sounds like a bizarre API to me. Access or properties should, as much as possible, behave just like normal data properties. > > > > OK. What would you like to see for the specific API under discussion here? > > Assuming I'm understanding the background reading correctly, > > myFileInput.files = new FileList([aFile]); > myFileInput.files = new FileList([bFile, cFile]); Why is that better than myFileInput.files = [aFile]; myFileInput.files = [bFile, cFile]; I'd really like to avoid introducing new XList type for every type X that we add to the system. Taken to an extreme we'd get sillyness like FileListList? In this specific case, I stick to an earlier proposal that I made elsewhere: myFileInput.files returns a simple raw JS Array This array can be modified using normal JS Array functions, like any other Array can. myFileInput.files is settable to any other raw JS Array, i.e. myFileInput.files = ["a", 2, myFile3] works. x = [...]; myFileInput.files = x; myFileInput.files === x; always returns true Submitting ignores any non-Files in the Array When exactly the UI is updated is somewhat tricky. We can likely use Object.observe which would lead to updating at end-of-task I think. / Jonas
Received on Friday, 11 October 2013 17:34:59 UTC