IE question

[Jeff Pflueger]

I realize that there are issues with Internet Explorer and d3.
I have a visualization I developed here:
http://jeffpflueger.com/multi_media/bear100/bear100_2011_7.php

and would like to know about feasibility and potential approaches to
make it usable by people using IE < 9

Thanks for any help!
Jeff

[Kai Chang]

Try this: http://code.google.com/p/svgweb/

[Jon Frost]

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
follow up on this thread - https://github.com/mbostock/d3/issues/73

Thanks.

[Chris Hunter]

Jeff.

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.

Thanks,

Chris

[Jeff Pflueger]

Thanks all. And thanks Chris, love to see what you've done.

My primary question is:
Is svgweb really the best approach?
svgweb is impressive, but from what I've seen so far, svgweb is only
going to work for a very limited number of cases.

Where is the activity going in d3 development to render in ie8? Is
svgweb where (and should be where) the energy is?

I've experimented with integrating d3 and svgweb and would like to know
why you think this isn't working:

https://gist.github.com/1275742

http://bl.ocks.org/d/1275742/

The svgweb portion is working: Here it is rendered on my server:
http://jeffpflueger.com/multi_media/runvis/circle_test.php - can view in
ie8 and other browsers. on bl.ocks.org server, could be that MIME types
aren't added and/or that the data-path needs to be local and not a URL.

What isn't working is that svgweb isn't finding svg output from d3.
Any ideas why that is?

Thanks for the help on this,
Jeff

[Nate Vack]

On Mon, Oct 10, 2011 at 5:10 PM, Jeff Pflueger <je...@infouse.com> wrote:

> My primary question is:
> Is svgweb really the best approach?

The technique I'd most like to try is to do all the drawing with
Raphael instead of raw SVG -- the number of projects where I can
ignore IE8- is not yet large enough.

I think it's a big project, though, even just to make sure select()
and company work normally.

-n

[Chris Viau]

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);  

d3.select("#viz")

    .customSelectAll()

    .data(data)

    .enter().customAppend(function(d, i){

        paper.circle(40, i*50+40, 10);

    });

I can almost do it like this:

d3.select("#viz")

    .selectAll("div")

    .data(data)

    .enter().append("div")

    .each(function(d, i){

        paper.circle(40, i*50+40, 10);

    })

    .remove();

But would it be useful?

[Jeff Pflueger]

Nate,
Do you have an example of this?

[Nate Vack]

Nope. I think it'll be hard.

-n

[Chris Viau]

I managed to make this work as a proof of concept:

var raphaelSVG = d3.select("body")

       .append("raphael:circle")

       .attr("raphael:cx", 20)

       .attr("raphael:cy", 20)

       .attr("raphael:r", 20)

       .attr("raphael:stroke", "red");

raphaelSVG.append("raphael:rect")

    .attr("raphael:x", 20)

    .attr("raphael:y", 20)

    .attr("raphael:width", 20)

    .attr("raphael:height", 20)

    .attr("raphael:fill", "aliceblue");

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.

[Jeff Pflueger]

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
// no map in ie8, so using jQuery.map:
var data = jQuery.map(profile, function(d) {
return [ {dis: d.dis, ele: d.ele}];
} );

var profile_line = d3.svg.line()
.x(function(d) { return x(d.dis); })
.y(function(d) { return y(d.ele); });

// draw the profile with Raphael
var path = paper.path(profile_line(data)).attr({stroke:'#000000',
"stroke-width":'2', "stroke-linejoin": "round" });

[wimdows]

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
problem.

[wimdows]

I also tried the svgweb javascript library option, and I can't get
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.

[pax roman]

Hi everybody!

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

wimdows wants. 

Best wishes!

[wimdows]

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.)

[Chris Viau]

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?

[Jeff Pflueger]

On 10/19/11 6:17 AM, Chris Viau wrote:
> What do you think is the best solution?

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
solution in my opinion. Unless it were a plug-in as widely adopted as,
say, Flash

- From my experience, svgweb definitely is not a solution at this point
for anything but the most basic renderings.

[Nelson Minar]

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.

[wimdows]

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.

[Jason Davies]

On Wed, Oct 19, 2011 at 08:16:24AM -0700, wimdows wrote:
> 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.

Sounds like you should get yourself a VM running IE9 so you can test
yourself. As others have mentioned, D3 works in IE9, with the usual
caveats of cross-browser development. Unfortunately, the only way to
guarantee that your visualisation works in IE9 is to test it. Likewise
for other browsers; each has its quirks, some more than others.

--
Jason Davies, http://www.jasondavies.com/

[Chris Viau]

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.

[Jeff Pflueger]

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
and share what I come up with.

[Nate Vack]

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
> in my opinion. Unless it were a plug-in as widely adopted as, say, Flash

That was what I thought, too, until I tried it yesterday. Chrome Frame
no longer requires admin privileges and takes about twelve seconds to
install. It's a viable solution in a lot of environments -- and *much*
easier than doing something crazy with Raphael.

I certainly only advocate it in IE8-; your code should Just Work in
every other (modern) browser. A few tips that have helped me:

* jslint. Even if you need to make it ignore whitespace errors, it
catches so much stuff that makes browsers cry. And in my experience,
IE tends to be more strict in its implementation of the ECMAScript
spec than others. 'use strict' makes 'em work more similarly.

* If you're using console.log at all, do a check and define it in your
script. Don't rely on yourself commenting out all its uses.

* Get a copy of 'Javascript: The Good Parts' and read it once a year or so.

-n

[Jeff Pflueger]

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
jquery together to create visualizations for modern browsers as well as
IE7 and IE8:

http://jeffpflueger.com/content/d3-data-driven-documents-and-internet-explorer

[Nelson Minar]

Here are some notes of thing I learned about using d3, raphael and jquery together to create visualizations for modern browsers as well as IE7 and IE8:

http://jeffpflueger.com/content/d3-data-driven-documents-and-internet-explorer

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?

[Chris Viau]

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. 

[Chris Viau]

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.

[Chris Viau]

And it don't create a DOM element but only the markup to create the path attribute that can also be used with Raphael.

[Jeff Pflueger]

No....Raphael requires a string in SVG format like this: M10,20L30,40 in order to to create a path.
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 d3.geo.path function appears to project geographic coordinates into SVG path data - but I haven't messed with it.

[Nelson Minar]

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.

[Chris Viau]

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.

[Alexander Whillas]

On Oct 19, 8:19 pm, Nate Vack <njv...@wisc.edu> wrote:

> That was what I thought, too, until I tried it yesterday. Chrome Frame
> no longer requires admin privileges and takes about twelve seconds to
> install. It's a viable solution in a lot of environments -- and *much*
> easier than doing something crazy with Raphael.

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
what else.
- 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
yourself.

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
level implimentation.

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
whatever.

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....

[Chris Viau]

I agree. This cross-browser incompatibility is the only feature preventing D3 to be the most used graphics library for Javascript. But it's also one of the few libraries trying to stay pure and play by the rules, encouraging the industry to move forward. Every new addition to SVG, Canvas, WebGL, HTML5 audio API, etc. can be automatically plugged into D3 without changing the core. The most elegant way to solve this dilemma would be to open some core functionalities for external reimplementation. For example, .selectAll( ) could have a .selectGeneric( ) method or a way to hijack it to reimplement it for Raphael or Dojo. Do you have an idea of how to implement this so we can join our effort?

[Mike Bostock]

> For example, .selectAll( ) could have a .selectGeneric( ) method
> or a way to hijack it to reimplement it for Raphael or Dojo.

You can pass a function to select and selectAll, which is then used
directly to select elements (rather than using querySelector). Maybe
that would work?

Mike

[Daniel Holth]

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.

[Chris Viau]

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. 

[Daniel Holth]

https://gist.github.com/1371379

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.

[Chris Viau]

Good try. Here are other attempts at making svgweb to work with d3, if it can help: 

https://github.com/mbostock/d3/issues/73

https://github.com/mbostock/d3/issues/51

https://github.com/underbluewaters/d3/commit/eb25ee9e66e54f5fa18cecd472c74fbda6b3d801

https://github.com/underbluewaters/d3/blob/master/examples/bar/bar.html

https://gist.github.com/1275742

There was also a Protovis fork:

http://multimedia.journalism.berkeley.edu/tutorials/protovis-internet-explorer/protovis-svgweb/

[Alexander Whillas]

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
build from that. I already have a very basic version going and will
check it into git when its usable.