search

Incorecttarget / protovis-js

Automatically exported from code.google.com/p/protovis-js
1 stars 0 forks source link

IE support #15

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. protovis dont support IE
2.
3.

What is the expected output? What do you see instead?

Webpage error details

Message: Expected identifier, string or number
Line: 1
Char: 30000
Code: 0
URI: http://vis.stanford.edu/protovis/protovis.js

What version of the product are you using? On what operating system?
Vista
Please provide any additional information below.

Original issue reported on code.google.com by ng.tr.h...@gmail.com on 16 Apr 2009 at 2:46

GoogleCodeExporter commented 9 years ago

Original comment by mbost...@gmail.com on 20 Apr 2009 at 6:53

GoogleCodeExporter commented 9 years ago 
I imagine supporting IE would involve using VML as a base instead of SVG.  See
http://raphaeljs.com/ for a good vector library that supports both SVG and VML.

Original comment by jason.da...@gmail.com on 8 Aug 2009 at 5:54

GoogleCodeExporter commented 9 years ago 
I could imagine using something like this, now that it's available: 
http://code.google.com/p/svgweb/

Original comment by drjl...@gmail.com on 31 Aug 2009 at 7:53

GoogleCodeExporter commented 9 years ago 
Definitely, we're keeping an eye on SVG Web. We tried using it a few weeks ago 
and it didn't sufficiently support 
dynamic generation of SVG (e.g., 
http://code.google.com/p/svgweb/issues/detail?id=202). However, they're 
actively developing it, so it may become a viable solution in the near future.

We're got VML rendering working in-house, but we haven't released it yet. If 
SVG Web is better than our VML 
output, we'll use it instead, or consider supporting both.

Original comment by mbost...@gmail.com on 31 Aug 2009 at 10:33

GoogleCodeExporter commented 9 years ago 
Issue 29 has been merged into this issue.

Original comment by mbost...@gmail.com on 8 Sep 2009 at 4:48

GoogleCodeExporter commented 9 years ago 
It would help if you abstract the protovis rendering layer.  Instead of 
hard-coding the SVG manipulation (e.g., 
pv.Area.prototype.update directly creates an SVG polygon), have it invoke 
methods on the underlying surface 
(currently stored in the .svg property) to do the render.  Then we could 
drop-in replace the render surface with 
an adapter built on top of other rendering technologies, such as Raphael, 
Processing, SVG Web, Flash, etc.

Original comment by XboxFa...@gmail.com on 12 Sep 2009 at 5:56

GoogleCodeExporter commented 9 years ago 
This ("abstract the rendering layer") is implemented and will be part of the 
next release, which should be 
available as soon as I finish up some documentation... The way it will work is 
that that Mark classes generate a 
static scene graph (roughly speaking, a JSON literal with all of the evaluated 
property values); this gets passed to 
pv.Scene.updateAll, which is responsible for updating the display. This means 
you can swap in a different 
implementation of pv.Scene (e.g., Flash, VML).

Original comment by mbost...@gmail.com on 12 Sep 2009 at 6:07

GoogleCodeExporter commented 9 years ago 
Awesome, can't wait -- thanks!

Original comment by XboxFa...@gmail.com on 13 Sep 2009 at 2:02

GoogleCodeExporter commented 9 years ago 
How far down the lane is svgweb+protovis? Thanks.

Original comment by ish...@gmail.com on 8 Oct 2009 at 6:36

GoogleCodeExporter commented 9 years ago 
I'm also interested in IE support for protovis. It's the only thing keeping me 
from introducing it to public 
websites. Has anyone gotten an IE shiv working for SVG support yet? Just 
curious if there's an update, don't 
bother responding if there's nothing new yet. :-)

Original comment by Clinton....@gmail.com on 30 Oct 2009 at 2:46

GoogleCodeExporter commented 9 years ago 
This looks promising: http://code.google.com/p/svgweb/issues/detail?id=202#c18

I've been playing around with getting protovis working with this but no luck so 
far, and I'm about to go on 
holiday for a week.  Ten internets to anyone who can get protovis to render 
using the latest svgweb.

Original comment by jason.da...@gmail.com on 1 Nov 2009 at 7:25

GoogleCodeExporter commented 9 years ago 
Back from holiday, and I've hacked together a simple Protovis graph working in 
SVG Web!

The main problem with working this into a proper patch is that once I've 
dynamically
added the <svg> element via SVG Web, I have to wait for the 'SVGLoad' event to 
be
fired before continuing so that I have a correct reference to the SVG root 
element. 
So this seems to introduce an asynchronous element, which complicates things 
somewhat.

Suggestions for elegant solutions on the back of a postcard please.  In the 
meantime
I'm off to bed.

Original comment by jason.da...@gmail.com on 7 Nov 2009 at 1:51

GoogleCodeExporter commented 9 years ago 
Hi Jason, the async part is necessary unfortunately since that is required to 
load
the Flash in the background, which is an async process. It's one of the few 
places
that SVG Web has to expose its internal model. Feel free to ping me if you need 
help
or have questions. We are tracking a similar bug on porting Protovis to SVG Web 
here:

http://code.google.com/p/svgweb/issues/detail?id=399

Original comment by bradneub...@gmail.com on 24 Nov 2009 at 5:36

GoogleCodeExporter commented 9 years ago 
OK, I got a better patch for this to work, but there are a couple of issues:

1. In IE8 (haven't tested on other IE versions yet) it works on the first page 
load, but when the page is 
refreshed the SVGLoad event doesn't fire. However if you press [enter] in the 
address bar it works again.
2. In SVG-supporting browsers such as Firefox, it works with 
svg.render.forceflash=true, but when this is 
turned off, it no longer works. Again, this is due to the SVGLoad event not 
firing. Maybe there's a way to tell 
whether forceflash is on or off?

Instructions for patch: apply it to protovis-d3.1.js and then copy to 
samples/javascript-samples in an svgweb 
checkout. Then replace helloworld.html with the attached.

To test, run java -jar src/tools/webserver.jar and navigate to 
http://127.0.0.1:8080/samples/javascript-
samples/helloworld.html

Original comment by jason.da...@gmail.com on 24 Nov 2009 at 10:28

Attachments:

GoogleCodeExporter commented 9 years ago 
I have a protovis-intensive page with hundreds of sparklines. My hunch is that 
instantiating hundreds of flash 
controls in order to render these via svgweb is not going to work well from a 
performance perspective.

I have no idea if VML would be any better, but I'm curious as to its status 
with respect to comment #4 -- how far 
along is the VML backend?

Original comment by john.fir...@gmail.com on 1 Dec 2009 at 12:38

GoogleCodeExporter commented 9 years ago 
Here is a snapshot of the VML code from several months ago. It's no longer 
compatible with the latest version, 
so we can't just plug it in. But it's a reasonable starting point for getting 
VML output working again. If I get a 
chance I'll see if I can rework the code to be compatible with 3.1, and then we 
can work on feature compatibility 
for VML.

(Aside: I'm not strictly advocating VML. I think SVG Web + Flash is still an 
attractive option, and so might Raphael 
+ VML, or even excanvas + Flash, but I haven't yet had time to do a real 
comparison.)

Original comment by mbost...@gmail.com on 13 Dec 2009 at 6:13

Attachments:

GoogleCodeExporter commented 9 years ago 
Issue 42 has been merged into this issue.

Original comment by mbost...@gmail.com on 28 Dec 2009 at 7:28

GoogleCodeExporter commented 9 years ago 
I've reworked the code from comment 16 and have protovis 3.1 rendering in IE 
via VML.

I'll work on getting my changes released today (need to get cleared through 
corporate 
legal).

Original comment by john.fir...@gmail.com on 28 Dec 2009 at 8:32

GoogleCodeExporter commented 9 years ago 
Really looking forward to seeing that. Does it cover all of protovis's 
features? I can help 
with testing that.

Original comment by Clinton....@gmail.com on 28 Dec 2009 at 8:41

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
John, is it likely you'll be able to release your changes for IE support for 
3.1?

Original comment by drjl...@gmail.com on 12 Jan 2010 at 1:55

GoogleCodeExporter commented 9 years ago 
I've pushed my changes to a github project:

http://github.com/bigfix/protovis

Note that you'll need to run 'make', as I did not commit the rebuilt 
concatenated/minified js.

Original comment by john.fir...@gmail.com on 14 Jan 2010 at 3:02

GoogleCodeExporter commented 9 years ago 
Thanks John! I just loaded some of my protovis graphs using IE and they worked 
perfectly.

Original comment by jason.da...@gmail.com on 14 Jan 2010 at 8:43

GoogleCodeExporter commented 9 years ago 
Thanks John, this is really exciting!

The last code commit in this project is over three months ago. I hope I'm not 
rude to 
ask: is Protovis being developed someplace else, or is John's fork the only 
work going 
on? The design looks superb, I hope the project is more alive than it looks. :)

Original comment by gunnlau...@gmail.com on 14 Jan 2010 at 1:06

GoogleCodeExporter commented 9 years ago 
Hi John, sounds promising! I downloaded the files from github and uploaded them 
on my 
server. But then I am lost. The examples still don't work in IE. Maybe it has 
to do 
with the running of 'make'. What does that mean exactly? How do I run that?

Thanks

Original comment by irenehan...@gmail.com on 14 Jan 2010 at 2:24

GoogleCodeExporter commented 9 years ago 
I'm guessing you're running on a Windows box (and I really don't want that to 
sound 
demeaning!) The 'make' command runs a makefile to prepare a program/library for 
production use. You might want to download a Linux live cd to run the command. 
Or 
just convince (pay?) someone else with a linux or mac box to do it for you.

Original comment by Clinton....@gmail.com on 14 Jan 2010 at 2:35

GoogleCodeExporter commented 9 years ago 
I just forked it, ran make, and committed the updated files.

http://github.com/jasondavies/protovis

Original comment by jason.da...@gmail.com on 14 Jan 2010 at 2:41

GoogleCodeExporter commented 9 years ago 
Hi Irene,

it means you need to have a version of http://www.gnu.org/software/make/ 
installed 
and run the make command; this will run the building instructions in the 
Makefile to 
produce the final .js file to deploy. For that process to work, you will need 
to have 
yuicompressor-2.4.2.jar in the lib subdirectory. You can get that from here: 
http://developer.yahoo.com/yui/compressor/ and build it using ant — which you 
can 
get from http://ant.apache.org/

Original comment by gunnlau...@gmail.com on 14 Jan 2010 at 2:41

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
@gunnlaugur We are very much alive. These improvements and others appear in a 
future release in the 
not-too-distant future.

Original comment by mbost...@gmail.com on 14 Jan 2010 at 6:46

GoogleCodeExporter commented 9 years ago 
How would people feel about a separate protovis-ie.js include that adds VML 
support for IE? My thought is 
that you could include it with IE conditionals:

  <script src="protovis.js"></script>
  <!--[if IE]><script src="protovis-ie.js"></script><![endif]-->

This way, browsers that implement standard SVG don't pay the IE tax. This is 
fairly significant: 20% (69.2 kB 
vs. 57.6 kB). Another possibility is that protovis.js internally issues a 
request to load the protovis-ie.js file, but 
then we'd need to make assumptions about where the file is stored which is 
error-prone.

Original comment by mbost...@gmail.com on 15 Jan 2010 at 12:05

GoogleCodeExporter commented 9 years ago 
The split makes perfect sense to me. I would prefer the former approach, but 
not 
strongly.

Original comment by gunnlau...@gmail.com on 15 Jan 2010 at 12:49

GoogleCodeExporter commented 9 years ago 
Re comment 31: The approach using conditional comments sounds good to me.

Re comment 29: I'm not sure what the workaround posted accomplishes. What 
browser 
version are you using and what was the error message? Note that the IE 
implementation 
does not currently support IE8 in IE8 rendering mode, due to undocumented VML 
changes in IE8. See http://www.lrbabe.com/?p=104 for some background. I 
currently 
use the X-UA-Compatible meta-tag workaround described there to get it working 
on 
IE8.

Re comment 27: I'm hesitant to commit the built results. If protovis ends up 
moving to 
git or another DVCS (which I would wholeheartedly support), I think we will 
have to 
exclude generated code from version control. With multiple contributors and 
forks, it 
will become a merge headache otherwise.

Original comment by john.fir...@gmail.com on 15 Jan 2010 at 1:13

GoogleCodeExporter commented 9 years ago 
@john.firebaugh: true, built results don't really belong in version control. 
But github has 
the downloads tab for that.

Original comment by gunnlau...@gmail.com on 15 Jan 2010 at 10:54

GoogleCodeExporter commented 9 years ago 
@mbostock: Conditional comments sounds great. If people want to bundle IE 
support in 
the same file they can always just concatenate them together into one.

@john.firebaugh: Agreed, I just wanted to provide a quick solution for those 
without 
make. The downloads tab on github would indeed be a better solution.

Original comment by jason.da...@gmail.com on 15 Jan 2010 at 11:13

GoogleCodeExporter commented 9 years ago 
@john.firebaugh: You are right, using the X-UA-Compatible meta-tag workaround it
works fine. I mixed some things up, so I deleted my previous comment to avoid 
confusion.

Original comment by asr.m...@gmail.com on 15 Jan 2010 at 1:37

GoogleCodeExporter commented 9 years ago 
Have you considered running the rendering abstraction on top of raphaeljs? I 
think it 
would be a great way to avoid having to cook up separate rendering pathways for 
SVG 
and VML.

Original comment by davidomu...@gmail.com on 22 Jan 2010 at 12:29

GoogleCodeExporter commented 9 years ago 
Raphaël is a possibility, but it might limit our graphical output 
possibilities (as opposed to having access to 
everything SVG is capable of doing). But if we want feature parity on Internet 
Explorer, we can't use all of SVG's 
features anyway.

It would require loading raphael.js, which is 57 kB (20 kB GZIP'd), and this 
extra code would be required for all 
browsers rather than just Internet Explorer. On the other hand, our rendering 
code would likely be smaller, so 
the total code size increase may be less.

Original comment by mbost...@gmail.com on 22 Jan 2010 at 12:48

GoogleCodeExporter commented 9 years ago 
What I would be looking for from Raphaël is increased rendering consistency 
between IE 
and SVG browsers, decreased amount of time we have to spend finding workarounds 
for 
browser bugs (because their developers found them already), and better 
rendering 
performance. If it can give us any of those, I'm all for it.

Original comment by john.fir...@gmail.com on 22 Jan 2010 at 1:50

GoogleCodeExporter commented 9 years ago 
So I tried the build with VML support (with IE8 in EmulateIE7 mode), and even 
for
relatively simple graphs (6 series, 150 datapoints, a little interaction),
performance was so bad that IE could never really finish rendering. That's not 
too
surprising, given IE's horrible VML and DOM performance.

So how about we try SvgWeb again? They've fixed the Dynamic Root bug:
  http://code.google.com/p/svgweb/issues/detail?id=202#c18

All the fix requires is using a special method in place of the SVG standard 
interface:
 svgweb.appendChild(root, document.body);

Original comment by ksfiles on 5 Feb 2010 at 5:28

GoogleCodeExporter commented 9 years ago 
What did you mean by "a little interaction"? We cannot get mouse interactions 
to work
on IE, so if you have found a way to get them to work, please share.

As for SvgWeb, even if it was an option, there still needs to be a non-Flash 
option
for IE for those who do not want the Flash dependency.

Original comment by davidomu...@gmail.com on 11 Feb 2010 at 5:55

GoogleCodeExporter commented 9 years ago 
I've implemented a proof-of-concept integration of SVGWeb and protovis. It draws
everything I tried fine, renders in all the relevant browsers (including IE8) 
and
requires (almost) no changes to how you use protovis.

Attached is the replacement protovis debug v3.1 code.

There are currently three bugs:

1/ titles added via the title() method show up only in FireFox. This appears to 
be
some problem with how browsers+SVGWeb deal with namespaces.
2/ events, while propogated from the SVG do not trigger as the event we're given
doesn't have the expected 'target' object (it's missing $scene).

Another limitation exists - code within <script 
type='text/javascript-protovis'> will
not work correct in IE (it'll crash the IE tab) due to some infinite looping or 
other
weirdness. Instead, you should definitely wrap your rendering up in a 
window.onload
callback.

A demo can be seen at http://www.nsquaredsoftware.com/svgwebdemo/

Original comment by drjl...@gmail.com on 11 Feb 2010 at 7:26

Attachments:

GoogleCodeExporter commented 9 years ago 
I meant that in its original form (as viewed on webkit), it had interaction, 
not that
I succeeded in having any interaction with IE. As I said, I didn't even get IE 
to
complete the render.

If you're happy with IE's VML performance, then this is probably a nice 
solution for
you, rather than SvgWeb with Flash.

Original comment by ksfiles on 12 Feb 2010 at 3:54

GoogleCodeExporter commented 9 years ago 
@ksfiles, the poor performance may have been due to an infinite loop bug 
(http://groups.google.com/group/protovis/browse_thread/thread/8d727a4dddc1743e).
 I have 
pages with 20-30 charts, multiple series, interaction, etc and VML performance 
is not mind-
blowing but not terrible either.

I've just committed some preliminary work on IE interaction support.
VML events look to be buggy. I don't seem to be getting mouseout
events at all, and the scale interaction examples have some odd redraw
problems with the margins. If anyone wants to dive in there and find
some workarounds, be my guest.

http://github.com/bigfix/protovis/commit/9b54c1ebd28dd19e6e6ebbf8fcfa74ce4ca85d9
7

I also uploaded a .zip file which includes the generated javascript
files as of this commit, in case running make is a difficulty:

http://github.com/downloads/bigfix/protovis/protovis-9b54c1.zip

Original comment by john.fir...@gmail.com on 12 Feb 2010 at 10:04

GoogleCodeExporter commented 9 years ago 
This example

http://vis.stanford.edu/protovis/ex/def.html

is painfully slow in IE. And if you're extending it to 60-80 columns instead of 
the
40 it takes 20seconds to load. 

Is there any chance things like this can be accelerated under IE?

Original comment by rdji...@gmail.com on 23 Feb 2010 at 4:11

GoogleCodeExporter commented 9 years ago 
I don't see that behavior. That example loads virtually instantly for me in IE8.

Original comment by john.fir...@gmail.com on 25 Feb 2010 at 12:22

GoogleCodeExporter commented 9 years ago 
Here's the version I'm testing with, if you want to try it out.

Original comment by john.fir...@gmail.com on 25 Feb 2010 at 12:28

Attachments:

GoogleCodeExporter commented 9 years ago 
John, how are you building those files? Do you have any makefile, use some 
patch to
do it? (please redirect me to any previous comment if you've explain this 
process
before).

Also, just to be sure, this is svgweb, right? Not vml

Original comment by pmgal...@gmail.com on 25 Feb 2010 at 1:30

GoogleCodeExporter commented 9 years ago 
Sorry, I was referring to the VML implementation. That's what I've been working 
on. I 
guess we better be explicit about which implementation we're referring to. :)

I'm working in a git fork, and I use the Makefile that's included.

http://gitorious.org/~jfirebaugh/protovis/jfirebaughs-protovis

Original comment by john.fir...@gmail.com on 25 Feb 2010 at 1:39

GoogleCodeExporter commented 9 years ago 
Thanks for the explanation John.

There has been a lot of excellent work done on this subject, both on vml and 
svgweb,
and it's amazing how much better we are just compared to one month ago. Thanks 
for
everyone involved in this.

Is it too soon to ask for a comparison between both approaches? Not to trash 
any of
them - on the contrary, it's very reassuring to get such good results on both. 
But
there's been a lot of what I think are false statements regarding both of the
implementation, namely when in comes to interaction and performance.

Also, is it foreseeable that we can get to a point where a single protovis.js
provides support for all browsers (native + IE) in a single source, or the 
patches
intrinsically modify the way things work?

Original comment by pmgal...@gmail.com on 25 Feb 2010 at 2:00