Skip to main content

Bug Tracker

Side navigation

#10027 closed bug (wontfix)

Opened August 11, 2011 03:55PM UTC

Closed August 22, 2011 05:32PM UTC

Last modified March 14, 2012 08:27AM UTC

jQuery.hasData returns false for elements with HTML5 data- attributes in the markup

Reported by: Owned by: rwaldron
Priority: blocker Milestone:
Component: data Version: 1.6.1
Keywords: Cc:
Blocked by: Blocking:
<td id="test" data-priority="1">Description of status</td>
$.hasData(document.getElementById('test')); // returns false
$('#test').data(); // returns Object { priority: 1 }

If HTML5 data attributes are recognised by the data() method then $.hasData() should also recognise them.

Attachments (0)
Change History (10)

Changed August 11, 2011 04:00PM UTC by anonymous comment:1

As requested, here is a jsFiddle demonstrating above:

(view with eg Firebug console enabled)

Changed August 11, 2011 04:47PM UTC by rwaldron comment:2

component: unfileddata
owner: → rwaldron
priority: undecidedblocker
status: newassigned

Changed August 11, 2011 04:48PM UTC by rwaldron comment:3

milestone: None1.6.3

Changed August 11, 2011 05:20PM UTC by rwaldron comment:4

Further reduced test case:

Changed August 11, 2011 06:24PM UTC by dmethvin comment:5

We are unfortunately overloading a lot of meanings onto the word "data" here based on different standards and conventions. Originally it was just the "data" representing jQuery's data-binding feature but we have asymmetrically extended it to include the "data" representing the data- attributes on an element.

The reason .hasData() exists is to provide a way for jQuery internals to determine if a jQuery data object (i.e., an entry in jQuery.cache) exists for a DOM element *without actually creating one*. That cannot be done with because that method is documented to return a newly created and attached data object if none previously existed.

For performance reasons, we only grab the data- attributes once, the first time that is called to read an attribute that is not defined, or when it is first called to read the entire data object (see #8909). (Note that doesn't pull in data- attributes, but *will* read the cached values once they are cached.) If you ask for data- attributes after that, you're using cached values and not the actual attribute values off the markup.

If you need to answer the question "Tell me if any data- attributes are on this element at all -- I haven't got any idea of their possible names", and you want to know the *current* state as opposed to the jQuery-cached-data state of those values, you'll need to do what does -- enumerate *all* attributes, looking for ones starting data-. That could be expensive.

Can anyone come up with a common need for something like this? Since the internal jQuery.cache entry that reads won't necessarily match up with the real-time data- attributes I think it might do more harm than good to provide it.

And yes, I think we've made a mess of this.

Changed August 11, 2011 06:34PM UTC by dmethvin comment:6

blocking: → 10026

(In #10026) See discussion in #10027 though.

Changed August 22, 2011 05:32PM UTC by dmethvin comment:7

resolution: → wontfix
status: assignedclosed

If you need to find out whether there are any data- attributes, use $().data() and a for/in loop to examine the result. The required semantics of .hasData() do not allow it to go looking for data- attributes.

Changed August 22, 2011 05:35PM UTC by rwaldron comment:8

If you need a "hasData" solution, the following will sufficiently meet that need:

(function( $ ) {
    $.fn.hasData = function() {
        var data = jQuery(this).data();      

        for ( var prop in data ) { 
            return true; 
        return false;  
})( jQuery );



Changed August 26, 2011 01:45AM UTC by dmethvin comment:9

milestone: 1.6.3

Changed September 22, 2011 03:36AM UTC by rwaldron comment:10

blocking: 10026

(In #10026) We will not be directly writing to data-* attrs with the jQuery data api