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 16103 - Remove DOMStringList usage
Summary: Remove DOMStringList usage
Status: RESOLVED DUPLICATE of bug 28067
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: Indexed Database API (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: This bug has no owner yet - up for the taking
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-02-24 10:03 UTC by Anne
Modified: 2015-05-19 22:19 UTC (History)
11 users (show)

See Also:


Attachments

Description Anne 2012-02-24 10:03:56 UTC
It seems fairly likely we can remove DOMStringList from the platform in favor of using arrays everywhere. Since Indexed DB is still fairly new lets at least not introduce it there.
Comment 1 Anne 2012-03-02 11:17:55 UTC
Note that Web IDL platform arrays (what you get with DOMString[]) are not quite JavaScript arrays.
Comment 2 Israel Hilerio [MSFT] 2012-03-08 22:55:32 UTC
Move this request to IDB v2:
http://www.w3.org/2008/webapps/wiki/IndexedDatabaseFeatures#Feature_List
Comment 3 Glenn Maynard 2012-03-08 23:44:42 UTC
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.
Comment 4 Israel Hilerio [MSFT] 2012-03-08 23:51:27 UTC
Forgot to add a link to the working group discussions [1]:

[1]http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0904.html
Comment 5 Anne 2012-03-09 07:55:36 UTC
This cannot be deferred.
Comment 6 Joshua Bell 2012-03-09 17:13:03 UTC
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?
Comment 7 Anne 2012-03-09 17:17:13 UTC
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.
Comment 8 Odin Hørthe Omdal 2012-03-09 17:41:40 UTC
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.
Comment 9 Israel Hilerio [MSFT] 2012-03-10 00:23:52 UTC
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.
Comment 10 Jonas Sicking (Not reading bugmail) 2012-03-10 01:10:37 UTC
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
Comment 11 Anne 2012-03-10 08:18:40 UTC
The value is that we can simplify the platform by dropping DOMStringList from it.
Comment 12 Jonas Sicking (Not reading bugmail) 2012-03-10 08:34:33 UTC
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.
Comment 13 Anne 2012-03-10 08:57:25 UTC
(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.
Comment 14 Jonas Sicking (Not reading bugmail) 2012-03-12 06:25:35 UTC
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)
Comment 15 Anne 2012-03-12 08:11:46 UTC
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.
Comment 16 Jonas Sicking (Not reading bugmail) 2012-03-12 23:29:18 UTC
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.
Comment 17 Glenn Maynard 2012-03-12 23:32:39 UTC
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.
Comment 18 Jonas Sicking (Not reading bugmail) 2012-03-13 03:27:21 UTC
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.
Comment 19 Glenn Maynard 2012-03-13 03:59:20 UTC
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.
Comment 20 Jonas Sicking (Not reading bugmail) 2012-03-16 19:08:01 UTC
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.
Comment 21 Glenn Maynard 2012-03-16 19:50:46 UTC
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?)
Comment 22 Anne 2012-03-19 16:06:36 UTC
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()?
Comment 23 Israel Hilerio [MSFT] 2012-03-20 01:26:33 UTC
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().
Comment 24 Jonas Sicking (Not reading bugmail) 2012-03-24 00:58:53 UTC
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.
Comment 25 Joshua Bell 2015-05-19 22:19:10 UTC
Marking this as a dupe of the newer bug.

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