Bring back reading settings from data attributes
benpickles opened this issue · comments
@asafbrukarz I would prefer to use a namespace for the return of data attributes - data-peity-fill="red" for instance. What do you think?
@benpickles the namespace should be fine. But it should be somewhere in "breaking changes" mentioned specifically to make sure people will be able to update the code appropriately.
Well the breaking change of removing the feature was in version 3, this is a new feature! However, I do agree that changes need to be more visible, I will add entries from https://github.com/benpickles/peity/blob/d99db2ca721e6f2bcb1bbdfb9c848d2cef35a809/History.md to the website.
I've discovered a problem with this feature. Unfortunately, and for seemingly no good reason, jQuery modifies the keys of data attributes that it reads - for instance stroke-width gets transformed to strokeWidth. This means that by just passing the data object to Peity some intended settings won't be applied.
Yes, as per jQuery's documentation this was changed in v1.6 to conform to W3C specification.
Having a look at your code, however, it seems that most variables are camel cased, so your variable is actually named strokeWidth. Where do you expect to see a problem in merging camel cased names?
Thanks, I didn't know that.
Yes, you're right, it's not a big issue. I guess it just surprised me.
Take a look at this: https://github.com/benpickles/peity/compare/read-data-attributes
What do you think?
I think that's a sensible approach.
As all of the options for a chart sit within one element, there's also the option of configuring the defaults using something like:
<span class="pie" data-peity-options='{"fill": ["red", "#eeeeee"], "innerRadius": 4 }'></span>
This would save you from having to normalise any data coming from the prefix-ed attributes.
I don't have a preference either way though.
That is a much better idea 😄
Thanks for that, it works much better.
https://github.com/benpickles/peity/compare/read-data-attributes
Nice. And with only a few hundred bytes growth.
I've released version 3.1 with this feature. Thanks for your time and effort on this, it's interaction like this that makes open source worth doing.