Question: Who requires SVG support?

[julianshapiro]

I'm considering adding support for SVG element animation. By default, neither jQuery, nor Transit, nor Velocity support this. Why? Because most CSS properties don't take effect on SVG elements; you have to tween their HTML attributes (e.g. width='100%') directly.

CSS properties that already work by default for SVG elements:
opacity, 2D transforms (all browsers except Safari desktop and mobile)

What I'd be adding support for:
transform (full browser support), x, y, width, height, cx, cy, r, rx, ry, x1, y1, x2, y2 -- basically, anything that's numerically tweenable.

How it would work: Before an element is animated, there would be a check for node instanceof SVGElement. When Velocity detects this flag, it'll apply all properties directly to the SVG element's attributes instead of its style tag.

So here's the question, who would use this? Better yet, is anyone dying for this to be implemented?

I only consider this a valid consideration for Velocity if it helps people avoid having to load additional SVG animation libraries; if you still need whatever your current SVG solution is even once Velocity has integrated this support, then it's not worth supporting at all.

[legomushroom]

• I'd like to see full SVG support in a way of extension. No need to overblow codebase for it. Intend to work with SVG? - link additional file and you are in the game :)
• CSS transforms for SVG elements do not work nor in FF no in IE(3d at least).
• The idea of prototype check seems good for me.
• 👍 for the step callback.
• I have a gist where I'm collecting CSS properties for SVG https://gist.github.com/legomushroom/7397561

[exside]

would love svg support (no need for snap then =D), but also see the point of bloating the codebase...

[julianshapiro]

@exside, @legomushroom

There should be very minimal bloat if I implement this.

CSS transforms for SVG elements do not work nor in FF no in IE (3d at least).

Right, thanks for the reminder. Updated original post.

I have a gist where I'm collecting CSS properties for SVG https://gist.github.com/legomushroom/7397561

Awesome, Oleg! Bookmarked.

[frekw]

Hi!

I'm definitely interested in support for SVG animations. I'm currently using SVG.js as well as Snapsvg.js in two different projects, but the only use I have for both of them is animating x/y/transform properties.

It would be really nice to get rid of the huge overhead they impose for the animations use case, especially since e.g jQuery can be used to modify the SVG DOM just fine, jQuery + Velocity would be a great combination for more basic SVG animations.

[speculr]

yes please

[dashed]

+1.

[msurguy]

I was actually looking for SVG animations with velocity :)
Check this out to see how I would use it : http://codepen.io/msurguy/pen/rAved

But of course potential would be very big if I could do anything with SVGs like I could do with any DOM elements.

[bhongy]

I just changed all animations in my current project from Snap.svg to Velocity over the last weekend. Your API is way intuitive to work with, and I want all animation handlings to be queued and executed in one place (via Velocity).

I can do most animations that my project is required with only Velocity.js except doing something like transforming a path (like animating a shape from triangle to a square).

Currently, I use Snap to load my SVG spirtes then inject different fragments of the code into divs, then use Velocity.js to animate transform or opacity properties of the SVG elements.

So, supporting for SVG animation will be great. I hope to remove Snap from my project dependency - it is not the smallest library, and I just use it to load SVG sprites and animating shapes. I was thinking about implementing it myself but not confident that I'm good enough to deal with cross-browser quirks.

Hope it would not add much more weight to Velocity, else I think @legomushroom made a good point that having it as a plugin might be a good option.

[julianshapiro]

Hey Thanik!

I just changed all animations in my current project from Snap.svg to Velocity over the last weekend. Your API is way intuitive to work with, and I want all animation handlings to be queued and executed in one place (via Velocity).

Awesome. Thank you for the kind words :)

Hope it would not add much more weight to Velocity, else I think @legomushroom made a good point that having it as a plugin might be a good option.

I'll have it integrated directly into Velocity itself. It should barely add any weight. This will land in the next 14 days. Stay tuned! :)

[bhongy]

Hey Julian, awesome news! I really admire your great work on Velocity. Love the techniques you implement to cache DOM states and avoid querying it for computed values.

[julianshapiro]

How often do you use CSS transforms on SVG's as opposed to sticking with x, y, and the other native SVG attributes?

[ydaniv]

@julianshapiro I reckon transform usage is more common than xs and ys in SVG, especially for animations.

[julianshapiro]

Yeah, I'd agree. Problem is that it's not possible to support it on Android stock browser and all of IE unless there's an add-on to Velocity to provide CSS transform matrix math support.

I sort of feel like leaving it out altogether since people will complain that their SVG transforms aren't working in IE/AOSP.

[ydaniv]

I think that the inline transform attribute IS supported in all browsers, even though CSS transforms aren't.
See: http://msdn.microsoft.com/en-us/library/ie/bg124140(v=vs.85).aspx

[exside]

CSS transforms whenever possible =)

[julianshapiro]

I think that the inline transform attribute IS supported in all browsers, even though CSS transforms aren't.

You have to pass it a raw matrix/matrix3d value, though. Otherwise, only the scale transform works. No idea why.

[ydaniv]

IMHO, if it's trivial to add SVG support for modern browsers then adding that with the disclaimer that for additional support users need to add another plugin is totally legit.

[bhongy]

I primarily use opacity/transform to animate - just to keep the work in the composite layer to avoid repainting and layout recalculation (if I understand the discussion correctly). I have not tested in IE---will do it tonight.

What is your thoughts about changing all transforms to matrix and matrix3d based on the browser support? But keeping the API the same. (Like how GSAP do it).

If so, please let me know if there is anything that I can help.

[julianshapiro]

I don't think the same layout recalc issues would apply to SVG's since they have no concept of document flow. But I could be wrong; haven't checked into it yet.

Either way, there's one last thing I need: #120.

[thasmo]

+1

[bhongy]

d'oh! I never thought about that. It makes very much sense. It seems like anything in SVG gets repainted (using show paint rectangles in Chrome) during animation even with the translateZ hack.

[bhongy]

@julianshapiro, would stroke, stroke-width, fill, etc be a part of this SVG support additions? It might be just similar to backgroundColor, color, etc.

[julianshapiro]

Yup, I already built in support for those. :-)

Sent from my phone.

On Jun 23, 2014, at 12:29 PM, Thanik Bhongbhibhat [email protected] wrote:

@julianshapiro, would stroke, stroke-width, fill, etc be a part of this SVG support additions? It might be just similar to backgroundColor, color.

—
Reply to this email directly or view it on GitHub.

[bhongy]

Sweet!! 👍

[nexflo]

yup awesome! +1

[julianshapiro]

This took a tremendous amount of time, but only 80 additional lines of code. Woohoo!

See http://velocityjs.org/#svg for implementation details. Please test and report any issues in a new thread.

Enjoy!

[dashed]

@julianshapiro Awesome work! Really appreciate adding SVG support. Will be playing with the new features soon.

[tomByrer]

This took a tremendous amount of time, but only 80 additional lines of code.

Alot of my coding is like that; glad I'm not the only one ;)

only 2D (not 3D) CSS transform properties work with SVGs.

Is that because of flaky SVG support in browsers you decided not to add it, or...?

Thanks for your hard work!

[jonahbron]

I'm going to need to animate SVG elements, so I'll definitely be investigating this implementation. +1