This is preview!
data-doquery-range, and a library called "jJo" could use attributes names like
data-jjo-range." Requiring authors to prefix all data attr's with 'jquery-' is bit much to me, so this doesn't enforce such a thing.
Granular control is still available, by way of .attr(). The element attribute remains so if you just want to interact with it straight up, you can do that just fine.It seems like it would end up being somewhat limiting (and possibly confusing) to the end-user, who would lose granular control over the ability to choose one method over the other(for example, if they wanted to set a data-foo attribute, or get a data-foo attribute in an instance where a "foo" data had already been set)
I'm concerned about the possible performance considerations regarding checking data- attributes unnecessarily, in situations where the user isn't using them.Perf is certainly a consideration here. What's worth noting is that the data-* attr() call (and subsequent try/catch, JSON.parse) is only run if the internal data cache reports a miss. I couldn't think of any reasonable use cases for someone to be grabbing .data('missing') repeatedly with an unknown expectation if there will be data in the cache (or DOM) waiting for them.
It always reads the internal cache first. And: it never stores to the attribute, only reads from it.I think that plugin idea is good.It would first try to use browser native data store, right? And if not, would shove it on data-* ?
Yup. With the existing data() API, there is no good reason to set to data-* attributes.so you posit that the only value data- attributes have is for getting, and never for setting
Yup. (and if it's JSON, we'll parse it into an object)so every time you get .data( 'foo' ) if it's not set, you look at the data-foo attribute, and if that has a value, you set the data and return the value?