Note that Web IDL platform arrays (what you get with DOMString[]) are not quite JavaScript arrays.

Move this request to IDB v2:
http://www.w3.org/2008/webapps/wiki/IndexedDatabaseFeatures#Feature_List

It makes little to no sense, I think, to "later" removal of something.  Once it's later, it'll be in use and it'll be too late to remove it.

Forgot to add a link to the working group discussions [1]:

[1]http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0904.html

This cannot be deferred.

Are there any dependencies blocking this change elsewhere in spec-land?

This discussion...

http://www.mail-archive.com/es-discuss@mozilla.org/msg13698.html

...points out that DOMStringList could be replaced by normal JS arrays if Array.prototype.contains was implemented. Is that a requirement for dropping DOMStringList, or just a nice-to-have?

The places I know that use DOMStringList now are Indexed DB, HTMLPropertiesCollection.names (HTML), DataTransfer.types (HTML), and Document.styleSheetSets (CSSOM). They have all filed bugs against them to use DOMString[] instead (which is not a real JavaScript array, but a platform array, as I understand it) and will most likely be changed in the foreseeable future. None of them is in wide use so it's not too problematic.

It's not possible to /remove/ stuff like this, no, but it's possible to have incompatibilities (or extend). With incompatibilities, those who use some special feature from either DOMStringList or DOMString[] would have to work around those incompatibilities, and thus they'll write code that is futureproof when everyone converges on just using DOMString[].

Not getting this in feels a bit like an artificial hindering. And having two possible ways in the spec will make it a bit more vague. However, if it's really really impossible, I'd like to ask around and see if we could go down the incompat road in order to be able to actually converge on this later.

By the way, the email from Sicking said "possibly", and there's an unaswered reply to it:
  http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0908.html

--

Getting .contains() in ES arrays would maybe fix it though. Except for the name, but I haven't seen much code that isn't tests, that is relying on that.

We are committed to ship our current implementation, which uses DOMStringList. Our testing has shown interoperability with both Chrome and Firefox, which also support DOMStringList today.  It would be a shame to unnecessarily break existing interop.

Fixing this bug seems like it brings very small value to authors. The only benefit I could see is that extending Array.prototype would also extend the return value from various IDB methods.

I'd rather that by fixing DOMStringList such that it has Array.prototype on the prototype chain.

If we could additionally get Array.prototype.contains added then the switch to DOMString[] could be done compatibly (or at least compatibly enough). But that's of course up to TC39

The value is that we can simplify the platform by dropping DOMStringList from it.

We're talking a very small amount of value for web authors here.

But we can head in that direction if we mark the DOMStringList interface as [NoInterfaceObject] for now. That way it would be a basically completely backwards compatible change to replace DOMStringList with DOMString[] in the future when:

* Array.prototype.contains exists (Sounds like ES6 is getting it)
* Implementations have DOMString[] implemented

I'm inclined to punt on this until that time.

(In reply to comment #12)
> We're talking a very small amount of value for web authors here.

It's one less interface/API to learn.


> * Array.prototype.contains exists (Sounds like ES6 is getting it)

That means we cannot progress DOM4 until ES6 is out and depend on discussions in TC39. Historically (e.g. byte representation) that has turned out not so well. I want to remove DOMStringList from DOM4 as soon as possible.

I don't think this change is worth doing at this time. If you want to remove DOMStringList from DOM4, and IndexedDB is the only thing standing in the way of doing that, we can always move it into the IndexedDB spec for now (and hopefully remove it in v2 when DOMString[] is compatible)

The other reason I'm somewhat curious as to why ES6 would have this is that arrays already have indexOf. In any event, moving it to Indexed DB for now could work I suppose, although it's not really ideal.

Anne: Either way, can you mark DOMStringList as [NoInterfaceObject] for now? That'll make it easier to deprecate no matter which spec ends up defining it. We'd of course carry over that [NoInterfaceObject] attribute when moving the interface to the IDB spec.

It would seem strange if implementors would be willing to make the NoInterfaceObject change now, but not to just change it to an array.  It doesn't buy anything to stick NoInterfaceObject in the IDL if that won't actually be implemented any more quickly.

The two seems very different.

First off, making DOMStringList a [NoInterfaceObject] only affects code which explicitly messes around with the 'DOMStringList' global object. Messing around with prototype objects is still a relatively rare thing to do, especially for a rarely used interface like DOMStringList (I've only ever seen people do it with Node-related interfaces, though I'm sure others exist).

Second, changing DOMStringList to DOMString[] right now is *not* a backwards compatible operation given that you loose the .contains function (until ES6 grows that function).

Third, at least in gecko we don't yet have support for [] in our binding code at all. I.e. we never map in Array methods anywhere on the prototype chain.


So yes, I would say it's quite a bigger change.

But isn't the entire point that compatibility isn't an issue here, since there isn't yet existing code to break?  I thought the objection was to making changes to IndexedDB at all, not that doing this would cause web compat problems.

I didn't talk about compatibility in my previous comment. I talked about ease of making changes to the implementation.

I really don't see the downside of simply making this change in v2 once ECMAScript has grown an Array.contains method.

http://www.mail-archive.com/es-discuss@mozilla.org/msg13698.html

Anne, let me know when you are ready to remove DOMStringList from DOM4 so that I can add it to the IndexedDB spec. Alternatively, could you just make DOMStringList as [NoInterfaceObject] in DOM4 for now? I suspect that every day we delay this makes it less likely that microsoft less likely to make this change in their implementation.

You did talk about compatibility: "only affects code which...", "*not* a backwards compatible operation".  My point was that compatibility concerns don't seem to be the MSFT objection; their objection seems to be making any kind of noncritical change at all.

(Israel--any comment on the NoInterfaceObject change?)

FYI: The [NoInterfaceObject] change was made a while ago. It still strikes me as odd that we only keep this interface around for content that's not at all cross browser yet and could easily be modified to use something other than contains(). Is there even evidence of content using contains()?

I know for sure about one major product that is currently using contains() in relationship with IndexedDB.  There are least a dozen others that I know are using IDB but I'm not as closed to their implementation to know if they are using contains().

Yeah, I think .contains is a good API and it appears that TC39 agrees based on the thread linked to in comment 20.

If DOMStringList is marked as [NoInterfaceObject] then I think things are fine here and we can punt on making any changes until TC39 has added .contains, at which point switching to DOMString[] will be backwards compatible.

With that I'll move this to LATER.

Anne: If you want to remove DOMStringList from DOM-Core, let me know and I'll edit it into the IndexedDB spec.

Marking this as a dupe of the newer bug.

*** This bug has been marked as a duplicate of bug 28067 ***