That DOM 3 interface isn’t implemented in most browsers and doesn’t really do anything that the existing .data interface can’t/doesn’t. I’m not sure why we should implement it, as it seems to exist mostly for statically typed languages that can’t dynamically add properties to objects at runtime like JS. Can you provide some reasons why, other than “because it’s there”?

After this was filed last night, I spent some time reading up on the DOMUserData. I was hard pressed to find any valuable information beyond the spec.

You are correct, that it doesn't do anything much more than the .data interface, but I think that's the point. Two things to note though, 1) Its generally a compiled set of functions, and from initial testings, browsers that do implement it, can run the code slightly faster than jquery's .data function jitted, and significantly faster than the nonjitted function. And 2) from small tests (couple of thousand DIVs), seem to use less memory. I'm guessing this has to do with the fact, that jQuery is storing an "id" on the object as well as a "cache" array and These functions store the data on the DOM element itself.

I'm not sure why "because it's there", is not enough. I mean, jQuery feature tests querySelector and querySelectorAll, then attempts to use that when it can. Isn't using a native browser function, going to be better in the long run?

So, with regards to the comparison to qSA, nearly all browsers support qSA (even IE8) and it is significantly faster and more feature-complete than Sizzle, so using it is a no-brainer.

get/setUserData, on the other hand is:

1. Not widely supported

2. Not terribly applicable to the browser DOMs since we can set properties dynamically on DOM objects in JS (contrast to DOMs in other languages that are statically typed and/or have stricter access to host objects)

3. By your own admission, only slightly faster than our native implementation in browsers with JIT compilation—and browsers without JIT almost certainly won’t have support for this new interface

jQuery.data would not really need to exist at all but for the fact that IE’s garbage collector falls over when creating references between host (DOM) and JS objects. If we can ever drop it someday, it will likely be in lieu of performing direct property manipulation of DOM objects.

Adding support for new interfaces just because they exist only leads to larger and harder to maintain code with no tangible benefit, which seems to be the case here. If a more compelling reason can be made available for supporting this interface, we can reconsider it in a future version of the lib. :)

"Not terribly applicable to the browser DOMs since we can set properties dynamically on DOM objects in JS"

"jQuery.data would not really need to exist at all but for the fact that IE’s garbage collector falls over when creating references between host (DOM) and JS objects."

Wait... what? If you are talking about attributes on a DOM Node then thats not even remotely the same, setting attributes on a DOM only works with strings, making it completely useless for the rest of JS, unless you convert to JSON and back when you needed to, which would slow it down by a factor of 10, compared to .data()(Webkit/Gecko put the string [object Object] instead of the object in the attribute). If you are talking about DOM properties, the only jquery way of setting them is to "break out" of jquery, i.e. $('#selector').get(0).myprop = value;. Which defeats the point of using jquery. is there a plan for $.property("value", obj) ?

I can understand if you don't want to implement, but to imply that .data() is complete worthless, is crazy. You can not set an attribute to be a JS created object, giving $.attr() a far more reason to not exist.

If webkit+gecko which is 40% of the browser market, is "not widely supported" then so be it. I just know that by setting javascript data onto 5000 dom elements, ~5s directly using .setUserData, ~8s using jquery .data() modification to use .setUserData, and ~20s to use .data(), at least on one browser. Being slightly faster over a large set can have huge implications.

Also, isn't qSA way harder to support as not all selector engines are created equal? Personally, I like using .data/.setUserData because its "key" values don't conflict with attributes on the DOM Element (i.e. I can use Id and className or class, without worrying about it screwing with the dom elements styles and functionality), also, the inconsistency with how jquery processes attributes, with it assuming ele.property and ele.setAttribute('property') to mean the same thing, when in most browsers it is not the case.

var obj = { "this": "that" };

$('#testing').attr("myvalue", obj);

$('#testing').get(0).myvalue = 123;

console.log($('#testing').attr("myvalue")); // G/Wk/IE8+/O = 123

console.log($('#testing').get(0).myvalue); // G/Wk/IE8+/O = 123

console.log($('#testing').get(0).getAttribute('myvalue')); // G/Wk/O = "[object Object]" IE8+ = 123

I would assume that what ever goes through .attr() should be what comes back. Its these inconsistencies, that make .data/.setUserData far more attractive, for its consistancies.