Closed mhemesath closed 12 years ago
I'm leaning on magic at this point. I was at a visualization event at Trulia this week and talking about a 'drop in browser compatibility library for D3' made a loooot of eyes light up. I think 100% 'drop in' won't be possible like you mentioned, with CSS and transformations, but I think the less code that has to be edited to go from d3 -> r2d3 the better.
I think ideally, the intro to the library would be: "here's a library you can drop in. To make it work, you'll have to update your css and if you want transformations in ie, change the following about your code:"
I've been making a bunch of examples with r2d3 to figure out the diffs in syntax. want me to make a list of what I find? Then we could get a better idea of how much of this magic we'd need to do.
Yeah, definitely make a list. I also need to get a test suite in here as soon as possible. The native D3 test suite with the r2d3 module replacements is currently failing on a coule of tests so I need to look at that and address that as well.
But yeah, either create a list of items or go ahead and log a bug for each one to give transparency to what's missing.
And to finish this issue.. I'll go ahead and remove the raphael syntax and override SVG.
I updated to the latest d3 and fixed the failing tests (I had a bug). The tests still fail on travis, but it seems to be due to a failure in the test setup.
Closing this issue and moving the convo over to https://github.com/mhemesath/r2d3/pull/13
If we want to push this lib in the direction of a drop in replace for D3, we may consider dropping the d3.raphael method. Instead, r2d3 could override SVG append and generate a paper element instead. This has the benefit of staying more consistent to d3 native, but on the other hand is a little bit more magic.
@mbecica I'd appreciate your feedback on this.