|IE question||Jeff Pflueger||10/6/11 2:15 PM|
I realize that there are issues with Internet Explorer and d3.
I have a visualization I developed here:
and would like to know about feasibility and potential approaches to
Thanks for any help!
|Re: IE question||Kai Chang||10/6/11 8:28 PM|
Try this: http://code.google.com/p/svgweb/
|Re: IE question||Jon Frost||10/7/11 8:02 AM|
There was an issue open on this a while back and it might work well
without much fiddling.
If you get SvgWeb working with D3, it would be great if you could
|Re: IE question||Chris Hunter||10/8/11 9:00 PM|
I've been using an older branch of D3 that included svgweb support to get IE compatibliity. And it's worked but so far my visualizations have been largely static. So, I'd say that getting the animation working would be the riskiest piece.
You can check out my branch https://github.com/jugglebird/d3 to see if it works for you. If not, I'd be interested in what parts are working and what further changes might be needed.
On Thu, Oct 6, 2011 at 4:15 PM, Jeff Pflueger <je...@infouse.com> wrote:
|Re: IE question||Jeff Pflueger||10/10/11 3:10 PM|
Thanks all. And thanks Chris, love to see what you've done.
My primary question is:
Where is the activity going in d3 development to render in ie8? Is
I've experimented with integrating d3 and svgweb and would like to know
The svgweb portion is working: Here it is rendered on my server:
What isn't working is that svgweb isn't finding svg output from d3.
Thanks for the help on this,
|Re: IE question||Nate Vack||10/10/11 9:12 PM|
On Mon, Oct 10, 2011 at 5:10 PM, Jeff Pflueger <je...@infouse.com> wrote:
> My primary question is:
The technique I'd most like to try is to do all the drawing with
I think it's a big project, though, even just to make sure select()
|Re: IE question||Chris Viau||10/10/11 11:21 PM|
What if we could just hijack the d3 selection updating and appending to use another library for rendering (like dojo.GFX can use SVG, VML, canvas and SIlverlight)? It could look like:
var data = [100, 40, 20, 50];
var paper = Raphael(document.getElementById("viz"), 0, 0, 600, 400);
paper.circle(40, i*50+40, 10);
I can almost do it like this:
|Re: IE question||Jeff Pflueger||10/11/11 8:44 AM|
Do you have an example of this?
|Re: IE question||Nate Vack||10/11/11 11:33 AM|
Nope. I think it'll be hard.
|Re: IE question||Chris Viau||10/18/11 9:57 PM|
I managed to make this work as a proof of concept:
var raphaelSVG = d3.select("body")
This pseudo-namespacing is ugly but it only required about 5 lines of code to make .append() and .attr() work with Raphael elements and attributes. If someone is interested, I can put the modified code on a repository.
|Re: IE question||Jeff Pflueger||10/18/11 10:33 PM|
That's really interesting! I would indeed like to see it on a repository!
For a truly messy way of using d3 and Raphael together see below. But I
am having success with it.
Example: using d3 to make the path string for Raphael:
// make the path string in d3
var profile_line = d3.svg.line()
// draw the profile with Raphael
|Re: IE question||wimdows||10/19/11 12:52 AM|
I tried Adobe SVGweb. It never works. And I wonder how outdated
software can be a solution for anything.
And as to the other solutions mentioned above: having to resort to
third party software doesn´t strike me as a proper solution for the IE
|Re: IE question||wimdows||10/19/11 1:08 AM|
that to work either. In any case it does not strike me as the sort of
easy and practical solution everybody (more specifically potential d3
graph publishers( are looking for.
|Re: IE question||pax roman||10/19/11 3:02 AM|
Maybe there should be a tutorial on
how to get D3 graphs work with IE9 since lots of
people are having problems with that. I think this is what
|Re: IE question||wimdows||10/19/11 4:53 AM|
Yes, a tutorial would be marvellous! Although I was hoping for a
solution that is so simple it doesn´t really need a tutorial. But if I
read correctly from threads like these, writing any tutorial isn´t
going to be easy.
(Sorry if I sound somewhat critical or pessimistic btw. Up till a week
or so ago I have been nothing but optimistic about the ÏE caveat. But
having bumped my nose a couple of times recently, I have become
somewhat less sure about all this.)
|Re: IE question||Chris Viau||10/19/11 6:17 AM|
We all know the IE problem is IE itself. D3 is the most elegant library I know and closely follow HTML guidelines. I surely don't want its core to be all dirty with hacks just to make IE behaves. Making it work with IE9 is a start, but it only has 7% of market share yet according to W3Counter (September 2011), And the real problem is if we need to develop visualizations for business users. The bigger the business, the slower they update their browsers. The general solutions are:
-Develop without SVG. Pure HTML/CSS charts are more common than I previously thought
-Build the visualization server-side and just add interaction on the client side
-Use an abstraction over different rendering engine (Dojo.GFX, Raphael, Three.js)
-Use HTML5 Canvas. It's not well supported in IE but I think Ex-Canvas is doing a better job than SVGWeb to work in IE
-Use shims and polyfills, but I don't know of any that works easily for interactive stuff
-Make it static on IE and the full UX on real browsers
-Drop IE support
-Use Google Frame. That's probably the best solution
-Write two codes: SVG and VML. Do VML work in d3 out of the box?
Every hack to make d3 work with IE will also mean supporting IE on the rest of the code. I don't know if testing the d3 core in IE6 is a big priority.
But we still have to play with IE sometimes. What do you think is the best solution?
|Re: IE question||Jeff Pflueger||10/19/11 6:43 AM|
On 10/19/11 6:17 AM, Chris Viau wrote:I can chime in with some options which I think won't work:
- Requiring a rare plug-in download (Google Frames) isn't a great
- From my experience, svgweb definitely is not a solution at this point
|Re: IE question||Nelson Minar||10/19/11 7:09 AM|
For this discussion it's important to separate IE9 from older versions of IE.
D3 should work in IE9. Also, IE9 supports SVG, so most of the visualizations people are doing should work. No need for a library like Raphael or svgweb. IE9 is the least well tested browser for D3, so there may be the occasional bug, but it should work.
D3 may or may not work in IE8 and older versions. However, before IE9 Microsoft did not support SVG. Since most people are using D3 to do SVG, that means their visualizations do not work in IE8. Realistically, they never will. svgweb in theory might work but I don't think anyone's demonstrated that being very effective. The bridge to Raphael is interesting, but honestly if you're going to do that why not just use Raphael natively? (D3 does not itself require SVG; you can use it to manipulate any DOM. But in the past, D3 has had some bugs related to IE8's APIs and I dont't think there's much enthusiasm for fixing them.)
Summary: IE9 good. IE8 and before, bad.
|Re: IE question||wimdows||10/19/11 8:16 AM|
Wel, it is not my aim to make graphs for business people, but for news
media. Unfortunately the people working for these media are just as
conservative when it comes to browser preferences. They don´t like it
very much that D3 wont work on older IE versions, so they will want
guarantees everything works fine in IE9. I fully agree with the no-
hacks-wanted argument. (So, screw IE8.) But I would sleep a lot better
if I could promise that full IE9 compatibility, no holds barred.
So, it sure would be great to have some sort of checklist.
|Re: IE question||Jason Davies||10/19/11 8:24 AM|
On Wed, Oct 19, 2011 at 08:16:24AM -0700, wimdows wrote:
Sounds like you should get yourself a VM running IE9 so you can test
|Re: IE question||Chris Viau||10/19/11 9:14 AM|
This is less messy than my intrusive approach. Maybe we should concentrate on these kind of interoperability we could have with Raphael, like your line generator example. It can help improve D3 instead of pulling it back.
|Re: IE question||Jeff Pflueger||10/19/11 10:26 AM|
Glad you think so. Though it feels a bit messy to me.
And frankly, Raphael is a mess in comparison to d3! So my loyalties are
squarely with d3.
I will forge ahead then with playing with d3/Raphael interoperability
|Re: IE question||Nate Vack||10/19/11 12:19 PM|
On Wed, Oct 19, 2011 at 8:43 AM, Jeff Pflueger <je...@infouse.com> wrote:
> - Requiring a rare plug-in download (Google Frames) isn't a great solution
That was what I thought, too, until I tried it yesterday. Chrome Frame
I certainly only advocate it in IE8-; your code should Just Work in
* jslint. Even if you need to make it ignore whitespace errors, it
* If you're using console.log at all, do a check and define it in your
|Re: IE question||Jeff Pflueger||10/30/11 11:14 PM|
To finish the IE question thread here, I was able to cobble together
using d3 with Raphael to create a visualization that works in Internet
Explorer 7 and 8 as well as the browsers that understand SVG.
Here is the example: http://seeruns.com/runvis_final.php
Here are some notes of thing I learned about using d3, raphael and
|Re: IE question||Nelson Minar||10/31/11 6:47 AM|
Nice writeup! I'm curious about the last bit of code; it looks like you use d3.svg.line() to create an SVG DOM element that's the line, and then use paper.path() in Raphael to render the line. Does Raphael magically convert SVG to VML behind the scenes?
|Re: IE question||Chris Viau||10/31/11 7:04 AM|
Thanks for trying this route. I wonder what's remaining of D3 after you remove all IE<9 incompatibilities. You used some helpers and generators. What else? My other experiments with various shims didn't gave much results. One thing is clear for me now, D3 will never let you append and reselect in the DOM on IE<9 in a data-driven way without a lot of effort.
|Re: IE question||Chris Viau||10/31/11 7:09 AM|
That's the whole point. Raphael is an abstraction over SVG and VML and use a syntax close to SVG.
I suppose you could write elements in the VML namespace with D3. But you would have to maintain to different code for graphic generation.
|Re: IE question||Chris Viau||10/31/11 7:11 AM|
And it don't create a DOM element but only the markup to create the path attribute that can also be used with Raphael.
|Re: IE question||Jeff Pflueger||10/31/11 8:25 AM|
No....Raphael requires a string in SVG format like this:
I can't find a way to generate this string in Raphael, and writing something to generate this string is a major undertaking.
But d3 has the method to create exactly this string:
d3.svg.line() - which impressively returns a string to draw a path in SVG format.
There are likely other d3 methods which return strings that can be used by Raphael.
For instance, the
|Re: IE question||Nelson Minar||10/31/11 1:37 PM|
Oh, I didn't know Raphael could work with SVG paths like that. It sounds like a useful adapter could be written on top of d3.svg that emitted those to VML by using Raphael's code to translate. Not sure that's a good idea, but it might work.
|Re: IE question||Chris Viau||10/31/11 1:49 PM|
Raphael don't translate SVG into VML like some shims can do. It translates an abstract syntax close to SVG into SVG and VML, So integrating D3 with Raphael requires using this abstract layer (like using attr() instead of setAttribute() or setAttributeNS()). It can be done, like I said earlier on this thread. I will try to share my code soon, as previously requested.
|Re: IE question||Alexander Whillas||11/16/11 8:45 AM|
In my opinion I think integrating with something like Raphael is the
way forward. The main reasons are:
- Browsers will always need shims to make the ALL work the same. This
is the main lesson from the browser history if nothing else.
- This also means new platforms such as mobile phones and god knows
- Having some sort of abstraction layer means your code is more
portable. Say you want to port it to some offline application. Ideally
you solve a problem once and reuse everywhere. If your tied to a
particular implementation on a particular platform your limiting
Raphael uses something like the Abstract Factory design pattern
(http://en.wikipedia.org/wiki/Abstract_factory_pattern) so the
underlying implementation is behind a common interface. You might so
this with Raphael so that you can swap it out in the future for
something else just by writing an adapter interface to the new low
So you have a d3.line() method that just calls the d3.adapter.line(),
where adapter could be an interface to Raphael or dojo.gfx or TCL or
I have just found this lib today but maybe it wouldn't be so hard
(just boring) to abstract all the lower level calls to an Adapter
class and then write a Raphael implementation of this...?
might have a quick sniff....
|Re: IE question||Chris Viau||11/16/11 9:14 AM|
|Re: IE question||Mike Bostock||11/16/11 10:52 AM|
> For example, .selectAll( ) could have a .selectGeneric( ) method
You can pass a function to select and selectAll, which is then used
|Re: IE question||Daniel Holth||11/16/11 12:16 PM|
Have you tried using svgweb by putting the d3 code and <script> tags inside a blank svg file instead of in the HTML? This bypasses the whole browser -> plugin DOM issue since d3 is only running inside the svg.
|Re: IE question||Chris Viau||11/16/11 12:21 PM|
Can you give it a try? On my side, I will experiment with the .select() function argument with Raphael. If the same thing was possible with .append(), it would be a good start. But if svgweb could work, the problem would be nearly solved.
|Re: IE question||Daniel Holth||11/16/11 1:10 PM|
Square should turn green. I couldn't get it to work in svgweb (not included in the gist, obviously). Unfortunately svgweb doesn't support anything but inline scripts inside svg, so d3 and my script are CDATA. I don't know how to debug it.
For non-svgweb purposes, <script> inside the SVG is awesome. Especially if you draw part of the chart in a vector graphics program.
|Re: IE question||Chris Viau||11/16/11 1:28 PM|
Good try. Here are other attempts at making svgweb to work with d3, if it can help:
There was also a Protovis fork:
|Re: IE question||Alexander Whillas||11/24/11 8:58 AM|
I've started to work on my own library that sit on top of Raphael and
i'm going to use a similar API interface as d3.js but I might be a bit
more OOP focused . I might also make the core rendering (not
interaction) work in Canvas as an exercise to make sure i keep lower
API interface platform independent.
At the moment I only need a line chart so I'll start with this and