- From: François REMY <francois.remy.dev@outlook.com>
- Date: Fri, 11 Oct 2013 22:39:10 +0000
- To: Domenic Denicola <domenic@domenicdenicola.com>, Jonas Sicking <jonas@sicking.cc>
- CC: Boris Zbarsky <bzbarsky@mit.edu>, "public-script-coord@w3.org" <public-script-coord@w3.org>
- Message-ID: <DUB405-EAS385261BD78B35A071D0ADFFA51F0@phx.gbl>
What’s your proposal regarding what happens once the user uses the input to select new files after you modified the array in JS? I’m afraid you could get the operation to fail by setting a weird “length” property or changing the __proto__ of the array. Or do you expect user interaction to “set” a new array, therefore avoiding this weird issue? De : Domenic Denicola Envoyé : vendredi 11 octobre 2013 19:51 À : Jonas Sicking Cc : Boris Zbarsky, public-script-coord@w3.org This sounds great! I think in my long-ago message I was assuming that Object.observe-like technology would be unavailable. Or that there was a constraint that the returned value be frozen (even if the property was itself settable). I hope this gets implemented as you propose, as that's exactly how it should work! From: Jonas Sicking Sent: 10/11/2013 19:34 To: Domenic Denicola Cc: Boris Zbarsky; public-script-coord@w3.org Subject: RE: Allowing IDL attributes to have different types for the getter and setter 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 22:42:17 UTC