Add class support to d34r `selection.(select|selectAll)` about d34raphael HOT 13 CLOSED

As far as I'm aware Raphael doesn't support classes at all natively; would the solution be to drill through to the elem.node?

PS the documentation currently uses .attr('class','point') despite it not working.

from d34raphael.

Never mind, the issue is that the .attr({ ... }) syntax doesn't support class.

from d34raphael.

Downside of this split repository approach is that I can't directly attach a pull request to this issue. See here instead:
webmonarch/d3#1

from d34raphael.

@clint-tseng Thanks. I've updated the issue description to more clearly explain my intent.

RE: the selection.attr({attrName: attrVal}) syntax: right now, d34r selection.attr call follows the API set by d3. The .attr({name: val, name: val}) syntax is part of Raphael Element.attr call.

Let me know if I miss-understood. I will take a look at the pull-request.

from d34raphael.

RE: the {} syntax, I think it's important to be consistent, so the API should either accept { class: '...' }, or we should make .attr('class', '...') throw not supported and force people to use .classed(...) instead. I think aesthetically the latter mirrors Raphael better, but the former certainly eases transitional issues from standard D3.

from d34raphael.

@clint-tseng I expect selection.attr("class", "classname") to work on d34r. It's used in all the examples.

from d34raphael.

Yes, and it does. But, selection.attr({ class: 'className' }) does not. The inconsistency there is somewhat confusing in my mind.

from d34raphael.

I agree with webmonarch. You can't use class because it's a reserved word and the browser will tell you so, it's not an inconsistency.

from d34raphael.

But that's not why it doesn't work, right? I could easily (and I do) use { 'class': 'className' }. It works in D3. I think it's confusing that it doesn't work in D34r. I'm not trying to make any religious argument here, I'm just trying to point out an inconsistency in the API that cost me a couple of hours.

from d34raphael.

It is not an inconsistency with the API, it is a consistency with JavaScript. class is not the same as "class". For this same reason class name properties are assigned to elements via className instead of class. class is a reserved word.

from d34raphael.

Hrm. I see what you're saying. On the other hand, I could swear that last week I was using { 'class': 'className' } in raw d3 and it was working fine. If it's well-known that one should use { className: 'className' } then I defer to that.

I still think it's odd that we allow .attr('class', 'className') if the .attr({'class', 'className'}) version isn't supported, though.

from d34raphael.

className is not a raphael or D3 convention, its what the DOM uses to assign class names to elements.

As far as .attr('class', 'className') goes, the goal of d34raphael is to make an IE compatible version of D3 that resembles the original D3 as close as possible. The fact that Raphael is used as a compatibility layer for a SVG fallback should be exposed as little as possible.

from d34raphael.

Resolved between webmonarch/d3#1 and webmonarch/d3@c6ac75c

from d34raphael.