Agreed, the underscore in the data-attribute isn't ideal. I initially tried to use camelCase, but alas, we often forget that DOM elements are case-insensitive:
Why not stick to conventions and go with dashes? Underscores are out of place in Javascript and the DOM... If I'm going to be forced to use underscore_case in Rendr that's different than the rest of my codebase (or other codebases I don't control which are all camelCase in Javascript) it's going to feel more unclean from the start.
Or you could say I'm not forced to use it, but now I'm using camelCase for variables and underscore_case for data attributes... so the two don't match, so why have the non-standard underscore_case at all.
(This would be an example of one of the things that makes libraries feel cludgy, and one of the reasons I love how consistent Backbone is, like I was talking about further up the thread with Jashkenas.)
I'm open to that. Like I've said, there's definitely room for cleanup of the implementation. Either way, this isn't a detail that's exposed to the application developer.
Yeah, it's unfortunate that all of Javascript uses camelCase instead of underscores, but since it does I'd rather use it everywhere, instead of using underscores when they aren't standard in either Javascript or HTML.
I have thought about this one too in my own applications, and I seem to switch back and forth.
The good thing about using underscore is that the variable name can match on both sides of the expression:
vs Mixing camelCase with dash seems a bit weird for me, because now there is a delimiter delimited, and case delimited convention: `data-modelId`.I am trying to use camelCase for new code in other parts of the code though, as it seems to be the general convention in JS. [0]
[0] http://ozmm.org/posts/javascript_style.html