I don't see the animations on iOS 6 and Android mobile devices. Why not?
According to this advanced SVG is not supported by Android.
Snap – A JavaScript SVG Library
51–60 of 60 posts
Re: Snap – A JavaScript SVG Library
#52today i recovered this http://web.archive.org/web/20080426161839/http://www.fragmen... via waybackmachine. i coded this in 2006 (its optimized for IE6 and the (at that time cutting edge now for a long time deprecated) adobe svg plugin). basically a LOGO like language in svg and js. the good news is: it still works (webkit), the bad news is that i still dont believe that SVG is the future. fool me once ...
Care to share why?
personal disappointment is pretty high up on the list: i was an early adopter SVG ninja, i believed in the revolution, and the revolution didn't happen.
and i understood why: SVG is a technology invented and specified by a committee built upon a technology invented and specified by a committee (XML). now combine this with the most anarchistic technology in the internet, i'm talking about the one technology that is still untamed in it's raw from, mischievous and sometimes plain dumbevil in it's details, yes, i'm talking about the DOM. that's why working with SVG always felt clunky and massochistic to me.
so if you touch SVG always use a high level clever abstraction. and well this seems the point of snap.svg. maybe i will give it another try. but the thing is, whenever i use a high level abstraction i will sooner or later go down into the pits again, because i want to know how it works and whatever else i can make it do, and then i will probably hate myself again for giving svg another shot....
Re: Snap – A JavaScript SVG Library
#53This library really looks great; I was wondering if charts (financial, statistics,...) are supported, for example, by connecting to data sources in JSON, etc
I wouldn't mind taking a closer look at that. They do have a data API to store individual key value pairs http://snapsvg.io/docs/#Element.data Definitely different than what I'm used to in D3js, but worst case scenario you would have to loop through each key value pair. Worth testing out.
You're right, noahmarc, it's the same for me, I'm now too used to working with D3j, that I definitely need to find my way in Snapsvg library, as it really looks promising; maybe it'd be better to arrange a high level specialized class library to handle not only worst case scenario, but even common chart functions, as the Api itself looks quite low level code...
Re: Snap – A JavaScript SVG Library
#54I find a bit strange not to have contributed in svg.js ( http://www.svgjs.com/ ). Not Invented Here ?
I've found svg.js unusable for any project I've had as it requires all svg content to be created with svg.js and no imports.
Re: Snap – A JavaScript SVG Library
#55Re: Snap – A JavaScript SVG Library
#56Wow. Snap looks beautiful. Nice one, Dmitry. I've been enjoying working on my own SVG library, Pablo[1]. It's inspired in part by the fun I've had using Raphael, and wanting to explore what can happen when SVG is a first-class citizen of a library. [1] http://pablojs.com
When I added the ability to import existing SVG images into Pablo, and to export the generated SVG in different image formats[1], I was pretty thrilled by the possibilities of having a JavaScript bridge between the design tools and the web app, the designer and the developer. And I see that Snap is also totally aligned to this kind of interaction between the web app and the external graphics tools, like Illustrator, Inkscape and SVG Edit.
The obvious next step is for a drop-dead simple visual interface to choreograph the graphics and the animations, with hooks into the rest of the JavaScript application. It could might be a game, interactive art, a visualisation or anything with graphics. Flash is dead, but there is nothing that exists for the open web that is as intuitive and fun to use as the Flash IDE was.
It must be just a matter of time before a tool as brilliant as the Flash IDE comes along for the open web, and I can imagine it makes a lot of sense for Adobe to be in on it.
Re: Snap – A JavaScript SVG Library
#57Libraries like this come up on HN on a regular basis it seems. As I read through the site I kept asking myself "this looks great and all, but can I depend on it in the long term?". Then I came across the "about" section where it says it was created by the creator of Raphael.js[1]. Say no more.. I'm in! [1] http://raphaeljs.com/
Why not just release a new version of RaphaelJS and stop supporting anything before IE9? He now has two very similar (but not compatible) libraries to support. Raphaël.js is great, btw.
I saw Dmitry's presentation yesterday over SnapSVG.
Raphael was, and is, meant to support older browsers. This comes with a cost of not being able to fully use everything SVG has to offer. Thus, Snap was born. He simply can't put everything into raphael to make it compatible with older browsers.
Raphael will still be getting bug fixes as the come in but is overall feature complete. In fact, Snap shares some of the same code raphael has, so maybe some bugs found in snap will be fixed in raphael as well.
Re: Snap – A JavaScript SVG Library
#58Check your mobile device performance with two quick demo links:
snap.svg coffee demo (click wheel to animate) http://snapsvg.io/demos/#coffee
d3.js chart demo (click buttons to animate) http://bl.ocks.org/mbostock/3943967
Re: Snap – A JavaScript SVG Library
#59Earlier quoted context omitted.
Care to share why?
personal disappointment is pretty high up on the list: i was an early adopter SVG ninja, i believed in the revolution, and the revolution didn't happen. and i understood why: SVG is a technology invented and specified by a committee built upon a technology invented and specified by a committee (XML). now combine this with the most anarchistic technology in the internet, i'm talking about the one technology that is st…
That's like saying you don't believe in memory allocation and pointers because they're "untamed" and "mischievous". Sure, low-level APIs/formats are a pain to work with, but that's the whole point of abstractions like this. If you hate yourself for learning how something low-level works, that sounds like a personal problem. :)
Re: Snap – A JavaScript SVG Library
#60Earlier quoted context omitted.
SMIL is the SVG animation markup. Sadly very few people have every used it. SvgWow.com has a bunch of great examples like: http://svg-wow.org/camera/camera.xhtml
There's an awful lot of Javascript backing that animation, I can't see where it's being turned into SMIL. At the very least it's definitely not static on the page, since the definition of the animation is entirely in JS: http://svg-wow.org/camera/camera.js Does it write SMIL somewhere near the end and then let it run, or does it just run in JS? Skimming through I couldn't tell, but I don't really have time to read mo…
Some JS is still used, certainly. However you can define the animation steps, timings, recursion, panning, zooming and many other facets purely in SVG/SMIL. When I wrote a financial world map visualization and drill down tool, 95% of the animation logic was in SVG/SMIL. The JS just called start/stop on the various animation elements.