This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Bug 23682 seems to be solving the issue of how to return a JS-array of Foo objects rather than having to introduce new FooList types. This means that we can remove FileList. This should be a backwards compatible change spec-wise. Some implementations supports the syntax myfilelist.item(5) which would be lost in this change. But given that no one has asked for the .item function to be brought back, hopefully this should be fine.
So we don't have to fix IDB implementation to support it :)
OK, but what is the best strategy for feature requests? For example, Bug 17125 calls for a .drop(itemNumber) method to be added. Without a custom interface, what can we extend or work with?
That's the beauty. If we use the proposed solution in bug 23682 and use Arrays rather than FileList, then we leverage the existing feature set of Arrays. I.e. things like FileList.drop(whatever) isn't needed since Arrays already have that functionality.
(In reply to Jonas Sicking from comment #3) > That's the beauty. If we use the proposed solution in bug 23682 and use > Arrays rather than FileList, then we leverage the existing feature set of > Arrays. I.e. things like FileList.drop(whatever) isn't needed since Arrays > already have that functionality. I guess in the case of something like FileList, all "new proposal" operations (like .drop(item)) will be list operations envisioned for an iterable type, which I guess Array gives us out of the box. OK, I'm sold :)
We've marked this "at risk" but haven't removed it, owing to the other platform bits that need to happen.
Once bug 23682 is fixed, we can probably just do |typedef FileList FrozenArray<File>;|. This way we don't have to depend on others to remove it from their spec.
We're migrating File API bugs to GitHub Issues; this one is: https://github.com/w3c/FileAPI/issues/19