Yep, that's intentional. We can't reliably bind data to object elements without the potential for un-catchable exceptions from occurring. The problem is that when we attach our expando to the object element it's going directly in to the internal plugin - frequently (as is the case with java applets) an uncatchable exception will be thrown that we can't work around. It is a huge bummer but having applications crash was a bigger bummer.

I have created a simple patch that restores data() support for Flash objects, while forbidding support for other applets. It also offers more flexibility than the current noData approach, which would allow someone to easily add data() support for, say, Silverlight outside of the framework.

Flash object tags always have the same classid attribute. So it's reasonably safe to hard code it. However, if this is something the team isn't cool with, I recommend keeping my patch and just changing noDataElems to

noDataElems: {

"embed": true,

"object": true,

"applet": true

}

Then plugins can simply override that value and add custom functions to give data() support for their desired elements.

My proposed noData function can be further compacted into:

noData: function(elem) {

var isBanned = jQuery.noDataElems[elem.nodeName.toLowerCase()];

return !isBanned ? false : (jQuery.isFunction(isBanned) ? isBanned(elem) : true);

}

It's your call on that one.

Also, should we perhaps throw an error by default for this case? If the patch was adopted the developer could override the throw and go back to silent fail.

Fixed http://github.com/jquery/jquery/commit/76db8a98220b6d76e98536b9578919bfb70048ed