I think jq's data methods allow you to store any type of object. So in the example above, '60' would be stored as a Number and not a String. When you extract it, you would get the Number and this helps if you want to do any math on the value.

Since you can't really set element attributes to non-string values, trying to sync the 'data' values with element attributes raises all sorts of unwanted problems.

Guessing, but it's probably because $.fn.data is meant as a storage mechanism, not a DOM manipulation mechanism. Changing the DOM attribute would make it just that tiny bit more expensive and you can already use $.fn.attr to do the same thing.

$.data is tightly bound to the DOM however - much of jQuery is, in order to reduce developer friction - so this is just more jQuery api asymmetry IMO.

To your point, performance is noble goal. Having some asymmetry is no big deal.

Thanks for this saraid216 :)

It's always good to know things like this.

Thanks again!

Yeah now this rings a bell I did have a go at using it like this before but the DOM didn't update as mentioned so I reverted to using it how I wrote above.

Thanks