This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
In various places in the spec such as the interpretation of key path values, the spec explicitly defines special input for ECMAScript Arrays. Most of the rest of the platform defines this via WebIDL's ECMAScript binding which is closer to "duck typing" rather than "is-a". For example, an operation that accepts sequence<DOMString> would be satisfied by this input: { 'length': 2, '0': 'first', '1': 'second' } ... even though it is not an ECMAScript array. This applies most easily to Key Paths, which are defined to be DOMStrings or Arrays of DOMStrings. ... Both Chrome and Firefox do "is-a" checks here, but changing this wouldn't break anything. I don't think we need to do this for the v1 edition of the spec, but adhering more closely to WebIDL for v2 would be nice.
For what it's worht, the current key setup just makes no sense at all in WebIDL terms. When I looked into implementing it in a WebIDL binding for Firefox I had to just give up because it's completely nonsense. See http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0087.html (which was met with deafening silence). I think you do need to fix this for v1. Certainly I would be objecting to the spec going to REC in its current state...
(In reply to comment #1) > For what it's worht, the current key setup just makes no sense at all in > WebIDL terms. When I looked into implementing it in a WebIDL binding for > Firefox I had to just give up because it's completely nonsense. See > http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0087.html > (which was met with deafening silence). I must have missed that, but +1. To maintain the intent behind IDB (and compatibility with shipping implementations) it probably turns into a bunch of additions to WebIDL. Not a bad thing, but will require spec coordination.
It's not clear to me what parts of this really need to stay compatible with the mess implementations ship (nor how compatible they are with each other), for what it's worth. But yes, we may end up needing WebIDL changes, depending. Please coordinate with Cameron ASAP, because WebIDL is in CR, so if you actually want substantive changes to it they need to happen _soon_.
See 20582 for discussion around keys specifically, where we should probably take the spec in the other direction - less WebIDL, more ECMA-262.
The bulk of the WebIDL fragments have been updated to use sequence<T> and T[] and unions as appropriate. Bug 20582 cleans up the definition of keys to define them in terms of ECMAScript objects rather than a hybrid of ES and WebIDL. What's left is a smattering of uses of <code>Array</code> throughout the spec far away from the method input definitions. Most of those are around keys (which should now be correct) but some are around key paths; those should more abstractly refer to a sequences, lists, or sets, not the input type.
There are still issues here for keyPath. I filed bug 21555 on those.
(In reply to comment #5) > What's left is a smattering of uses of <code>Array</code> throughout the > spec far away from the method input definitions. Most of those are around > keys (which should now be correct) but some are around key paths; those > should more abstractly refer to a sequences, lists, or sets, not the input > type. (In reply to comment #6) > There are still issues here for keyPath. I filed bug 21555 on those. Apart from the issues in 21555, I've updated the places that describe array-type key paths to use sequence<DOMString> consistently in https://dvcs.w3.org/hg/IndexedDB/rev/5d920000beba The pedantic part of me would like to take this further and refer to them even more abstractly as "sequences of strings" but this is probably sufficient.