Proposed workarounds for IE7, IE8 issues

[Paul Felix]

Hi,

The dygraphs library uses ExplorerCanvas (excanvas) to render in IE7
and IE8. As we know, ExplorerCanvas is a nice, clean effort to
emulate HTML5 canvas by converting canvas calls to VML, but there are
some limitations when translating a pixel-based system to a vector/
object-based system. Specifically, an arbitrary area defined for
clipping or clearing doesn't easily translate to VML and whatever clip
capabilities it has, so ExplorerCanvas doesn't currently support that.

This limitation affects dygraphs in a few ways. I'll describe them and
talk about my proposed dygraphs patches that work around the issues.

NOTE: these workarounds only come into play when excanvas is being
used. In all other cases they don't get executed.

* Clipped plot area (http://code.google.com/p/dygraphs/issues/detail?
id=134)

dygraphs sets up a clip rect around the plot area to clip plot lines,
but this doesn't work in IE7/IE8. My proposed workaround creates div
elements that are placed around the plot area and take on the
background color of the graph's container div (or whichever ancestor
div has a non-transparent background color on up to the document's
bgColor).

Note, this workaround will not work properly in cases where the
container div (or ancestor) has a background image. Is it still a
reasonable workaround, or not worth it?

* Default interaction model's gray zoom area (http://code.google.com/
p/dygraphs/issues/detail?id=129)

The dygraphs default interaction model displays a gray area when the
user zooms in, but the IE7/IE8 user nevers sees it because the whole
interactive canvas layer is immediately getting cleared as a result of
erasing the previous highlight dots at the same time. My workaround
redraws the gray zoom area after the previous highlight dots have been
erased.

* Mouse interaction in the plot area and in the range selector

Mouse interaction in the plot area and in the range selector gets
interrupted by IE7/IE8 when the mouse is over a VML element, because
IE is grabbing the events. Also, any cursor style settings get
overidden when moving over a VML element. My workaround creates a div
over the plot area and a div over the pan section of the range
selector. These divs are styled with a background that has an
opacity=0 so the user can't see them, but the divs will capture all
mouse events. This was easy to do for the plot area because the
dygraphs code had already defined a "mouseEventElement" responsible
for handling all mouse events. Thus, when excanvas is being used, the
mouseEventElement is simply set to the special div.

You can see a version of dygraphs with these workarounds here:

http://www.renesys.com/~pfelix/dygraphs_ie.html

If there's interest, I would like to make another pull request with
these workarounds. I do consider it distasteful to have to include
workarounds like this in dygraphs, but we're only talking about a few
lines of code.

Paul

[Dan Vanderkam]

Thanks for digging into this, Paul. Responses inline....

On Tue, Aug 30, 2011 at 11:42 AM, Paul Felix <paul.er...@gmail.com> wrote:
> Hi,
>
> The dygraphs library uses ExplorerCanvas (excanvas) to render in IE7
> and IE8. As we know, ExplorerCanvas is a nice, clean effort to
> emulate HTML5 canvas by converting canvas calls to VML, but there are
> some limitations when translating a pixel-based system to a vector/
> object-based system. Specifically, an arbitrary area defined for
> clipping or clearing doesn't easily translate to VML and whatever clip
> capabilities it has, so ExplorerCanvas doesn't currently support that.
>
> This limitation affects dygraphs in a few ways. I'll describe them and
> talk about my proposed dygraphs patches that work around the issues.
>
> NOTE: these workarounds only come into play when excanvas is being
> used. In all other cases they don't get executed.
>
> * Clipped plot area (http://code.google.com/p/dygraphs/issues/detail?
> id=134)
>
> dygraphs sets up a clip rect around the plot area to clip plot lines,
> but this doesn't work in IE7/IE8. My proposed workaround creates div
> elements that are placed around the plot area and take on the
> background color of the graph's container div (or whichever ancestor
> div has a non-transparent background color on up to the document's
> bgColor).
>
> Note, this workaround will not work properly in cases where the
> container div (or ancestor) has a background image. Is it still a
> reasonable workaround, or not worth it?

The background image problem with this workaround does give me pause,
though I do expect that most users of dygraphs have a solid-colored
background.

The other issue is a bit trickier. You probably noticed that the
drawing canvas spans the entire dygraph div, rather than just the
charting area + the axis lines. The reason is that there are supposed
to be tick marks extending from the gridlines past the axis lines.
These are still drawn, but you can't see them. The reason is that
dygraphs used to have a problem with overdrawing in all browsers. I
added the clipping rectangles to paper over this, but wound up
papering over the tick marks, too.

I have a change which I haven't committed yet which fixes this by
setting a different clipping area for each drawing step. And that's
not something you can do with divs.

Hope that makes some sense. I'll try to dig up the code and send out a
demo. It's entirely likely that, despite these reservations, your div
trick is the right thing to do.

> * Default interaction model's gray zoom area  (http://code.google.com/
> p/dygraphs/issues/detail?id=129)
>
> The dygraphs default interaction model displays a gray area when the
> user zooms in, but the IE7/IE8 user nevers sees it because the whole
> interactive canvas layer is immediately getting cleared as a result of
> erasing the previous highlight dots at the same time. My workaround
> redraws the gray zoom area after the previous highlight dots have been
> erased.

Sounds good. Any downsides?

> * Mouse interaction in the plot area and in the range selector
>
> Mouse interaction in the plot area and in the range selector gets
> interrupted by IE7/IE8 when the mouse is over a VML element, because
> IE is grabbing the events. Also, any cursor style settings get
> overidden when moving over a VML element. My workaround creates a div
> over the plot area and a div over the pan section of the range
> selector. These divs are styled with a background that has an
> opacity=0 so the user can't see them, but the divs will capture all
> mouse events. This was easy to do for the plot area because the
> dygraphs code had already defined a "mouseEventElement" responsible
> for handling all mouse events. Thus, when excanvas is being used, the
> mouseEventElement is simply set to the special div.

Is there any reason not to do this in all browsers? I'd be fine
putting up a div to capture all mouse interactions.

One of the other outstanding questions re: IE support is why
dygraphs+excanvas is broken in IE8. Microsoft changed the VML system
in IE8 in a way that broke dygraphs. I believe it's an excanvas bug
(there's one line of excanvas.js which you can comment out to fix it),
but the excanvas author disagrees. I've never gotten to the bottom of
it, hence the doctype hack to make IE8 render pages as IE7.

Thanks again for working on this!

- Dan

[Paul Felix]

Yes, me too. Maybe the question is this. Is it acceptable to have plot
lines leak outside the plot area? To me, it is not acceptable, so a
solution to that problem, albeit with some limitations (like no
background image), is preferable.

> The other issue is a bit trickier. You probably noticed that the
> drawing canvas spans the entire dygraph div, rather than just the
> charting area + the axis lines. The reason is that there are supposed
> to be tick marks extending from the gridlines past the axis lines.
> These are still drawn, but you can't see them. The reason is that
> dygraphs used to have a problem with overdrawing in all browsers. I
> added the clipping rectangles to paper over this, but wound up
> papering over the tick marks, too.
>

Yes, I was going to bring that up at some point. Ironically, it's only
IE7/IE8 that fulfills your intent by showing the tick marks :)

> I have a change which I haven't committed yet which fixes this by
> setting a different clipping area for each drawing step. And that's
> not something you can do with divs.
>
> Hope that makes some sense. I'll try to dig up the code and send out a
> demo. It's entirely likely that, despite these reservations, your div
> trick is the right thing to do.

Sounds good. I might want to wait for that change. On that note, will
it be possible to turn off tick marks? In my current project, we
actually don't want the tick marks. One could set axisTickSize to
zero, I guess, but then there may be no space between the axis and its
labels?

>
> > * Default interaction model's gray zoom area  (http://code.google.com/
> > p/dygraphs/issues/detail?id=129)
>
> > The dygraphs default interaction model displays a gray area when the
> > user zooms in, but the IE7/IE8 user nevers sees it because the whole
> > interactive canvas layer is immediately getting cleared as a result of
> > erasing the previous highlight dots at the same time. My workaround
> > redraws the gray zoom area after the previous highlight dots have been
> > erased.
>
> Sounds good. Any downsides?

I have observed no downsides.

>
> > * Mouse interaction in the plot area and in the range selector
>
> > Mouse interaction in the plot area and in the range selector gets
> > interrupted by IE7/IE8 when the mouse is over a VML element, because
> > IE is grabbing the events. Also, any cursor style settings get
> > overidden when moving over a VML element. My workaround creates a div
> > over the plot area and a div over the pan section of the range
> > selector. These divs are styled with a background that has an
> > opacity=0 so the user can't see them, but the divs will capture all
> > mouse events. This was easy to do for the plot area because the
> > dygraphs code had already defined a "mouseEventElement" responsible
> > for handling all mouse events. Thus, when excanvas is being used, the
> > mouseEventElement is simply set to the special div.
>
> Is there any reason not to do this in all browsers? I'd be fine
> putting up a div to capture all mouse interactions.
>

Hmm, not sure other than the fact that there's yet another div piled
on (with opacity of zero). Maybe potiential drag on performance? I'm
inclined to not do that for all browsers.

> One of the other outstanding questions re: IE support is why
> dygraphs+excanvas is broken in IE8. Microsoft changed the VML system
> in IE8 in a way that broke dygraphs. I believe it's an excanvas bug
> (there's one line of excanvas.js which you can comment out to fix it),
> but the excanvas author disagrees. I've never gotten to the bottom of
> it, hence the doctype hack to make IE8 render pages as IE7.
>

It would be nice to get a good explanation from the excanvas author on
what the proper fix is, Having said that, I am happy with your
solution to make IE drop back to IE7. I'm impressed with how you found
the right combination with the doctype and that <meta> setting. That's
all very confusing to me.

Paul