protovis compatibility in internet explorer


A third way to render in IE is to use a branch of Protovis that was altered to use Google's SVGWeb. Jamie Love has done a terrific job of making sure it works well with Protovis and stays up to date with the latest developments. But it is not for the faint of heart. You will have to write some code a little differently and it takes a little work.

The great advantage of this technique is that Protovis graphics are converted into Flash 10 objects and animations are retained. The disadvantage is that Flash is not viewable on iPhones and iPads.

Here is Love's directions for using SVGWeb

Protovis Tests, Partially Applying SVGWeb

This protovis pre-3.2 includes a small number of changes over the top of protovis 3.2 that allow it to work with SVGWeb.

You can find a fork of the official Protovis source code with these changes at gitorious (


Or you can download the necessary files here:


To make protovis work using SVGWeb, you need to alter your coding style slightly, basically because you need to make it work under IE. Namely:
  • Conditionally include the SVGWeb svg.js file. You probably don't want to use SVGWeb for non-IE browsers (at least yet). You can do this, by, at the top of your HTML file: Make sure to you include 'svg.js' first - it MUST be the first javascript file you include. The 'data-path' attribute must reference the directory svg.swf is in.
  • Unless using a script type of text+protovis, don't use function expressions like function () a.b , instead you have to write long form: function () { return a.b; } . This is an IE limitation.

Bugs using SVGWeb

This SVGWeb implementation is not perfect. There are a few bugs and what-not to work out still:
  • Resizing the Protovis root panel does not also resize the flash <object> container containing the SVG. To do so, you need to identify and resize the <object> DOM element manually.
  • The title property does not work via SVGWeb. Use a label instead if possible.
  • Completely re-rendering a graph may not work. It seems a little flaky. That is - calling vis.render() on a visualisation previously rendered may or may not work. I'm sure this is fairly simple to fix.upate: This works fine on the polar clock example.
  • Creating a whole new visualistion (by going var vis = new pv.Panel() and rendering to the same div as a previous render may not work. This is to do with the underlying flash object not cleaning up correctly.
  • Text labels with a text size different to the default will have their vertical text-alignment be a little wrong. This is because the flash SVG renderer doesn't understand the concept of 'em' for text offsets.
  • The flash renderer is slower than native rendering, so frequent re-rendering of a graph will easily bog the browser down, and probably won't work (so don't try sub-1s re-rendering). This can be alleviated by only re-rendering child marks on the graph, and longer term we can probably find some performance improvements for it.
  • In SVGWeb, when nodes are rerendered, the re-render can cause SVGWeb to trigger a mouseover event for the newly renderer node. As many graphs re-render the same node, changing color etc, this causes an infinite stream of mouseover events.

    Therefore, be very careful on how you trigger color/graphical changes on mouseover. Ensure you don't re-render if on mouseover you get the same index. Also, try and avoid having a mouseout event on the same mark as the mouseover - instead try and add mouseout to your base panel, and mouseover to your mark (bar chart whatever).

  • The flash renderer doesn't seem to get circle's correct - see the polar clock for an example. This also occurs in other situations - e.g. see the antibiotics example.
  • Rotated text does not work with SVGWeb. This is due to a known limitation with the Flash SVG rendering. See this SVGWeb bug report for details. Sadly, SVGWeb also does not support SVG fonts referenced via a font-face definition (see this SVGWeb issue).

Download the example files.