Skip to main content

Bug Tracker

Side navigation

#8093 closed enhancement (wontfix)

Opened January 30, 2011 02:29AM UTC

Closed February 09, 2011 03:11PM UTC

Last modified February 10, 2011 04:26AM UTC

.data() or .userData() should use DOM lvl3 getUserData/setUserData

Reported by: hungry.rahly@gmail.com Owned by: hungry.rahly@gmail.com
Priority: low Milestone: 1.next
Component: data Version: 1.5
Keywords: Cc:
Blocked by: Blocking:
Description

.data() or .userData() should use the DOM lvl3 functions getUserdata and setUserData if available on the element.

http://www.w3.org/TR/DOM-Level-3-Core/core.html#Node3-getUserData

http://www.w3.org/TR/DOM-Level-3-Core/core.html#Node3-setUserData

If not, should fall back to normal method for storage of user data objects.

Attachments (0)
Change History (6)

Changed January 30, 2011 10:09PM UTC by snover comment:1

_comment0: 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. Can you provide some reasons why, other than “because it’s there”?1296425514598623
owner: → hungry.rahly@gmail.com
status: newpending

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”?

Changed January 30, 2011 10:12PM UTC by rwaldron comment:2

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.

Changed February 02, 2011 02:45AM UTC by jitter comment:3

component: unfileddata
priority: undecidedlow
version: 1.4.41.5

Changed February 09, 2011 08:25AM UTC by hungry.rahly@gmail.com comment:4

status: pendingnew

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?

Changed February 09, 2011 03:11PM UTC by snover comment:5

resolution: → wontfix
status: newclosed

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. :)

Changed February 10, 2011 04:26AM UTC by anonymous comment:6

"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.