Jump to content
Search Community

Scale broken on SVG text

killroy test
Moderator Tag

Warning: Please note

This thread was started before GSAP 3 was released. Some information, especially the syntax, may be out of date for GSAP 3. Please see the GSAP 3 migration guide and release notes for more information about how to update the code to GSAP 3's syntax. 

Recommended Posts

When invoking .to(..., ..., {scale: value}) GSAP seems to create a style="transform: scale()" property on the element which does not work inside SVG. It should be transform="scale()" which does work.

 

I'm guessing this is a negative interaction with the CSS plug-in. How can I force GSAP to use the correct property names?

 

The codepen demo demonstrates this by puling the scale value off _gsTransform in onUpdate and applying it to the "transform" attribute.

See the Pen jmxsb by anon (@anon) on CodePen

Link to comment
Share on other sites

Hello killroy, and Welcome to the Greensock Forum!

 

Since you are explicitly trying to animate the transform attribute.. you need to use the AttrPlugin add that transform  within the attr:{} object
 

// animates the CSS property transform
TweenLite.to("#element", 1.5, {transform:"scale(2)"});

// animates the transform attribute with attr: {} object
TweenLite.to("#element", 1.5, {attr:{transform:"scale(2)"}});

:

When animating attributes, GSAP uses the AttrPlugin:

 

http://greensock.com/docs/#/HTML5/Plugins/AttrPlugin/

 

Below is taken from AttrPlugin Docs:

 

Tweens any numeric attribute of a DOM element. For example, let's say your DOM element looks like this:

<rect id="rect" fill="none" x="0" y="0" width="500" height="400"></rect>

:

You could tween the "x", "y", "width", or "height" attributes using AttrPlugin like this:

TweenLite.to("#rect", 1, {attr:{x:100, y:50, width:100, height:100}, ease:Linear.easeNone});

:

You can tween an unlimited number of attributes simultaneously. Just use the associated property name inside the attr:{} object.

AttrPlugin is NOT intended to be used with CSS-related properties because the CSSPlugin already handles those.

 

Note: a common mistake is to forget to wrap attributes in a attr:{} object which is essential for specifying your intent.

 

TweenMax includes the AttrPlugin :)

 

Does that help? :)

Link to comment
Share on other sites

Since the transform attribute is a string, how can I animate the scale?

 

I updated the codepen to try this, which of course does not work:

 
t3.to("#text3", 1, {attr:{transform: 'scale(2)'}})
  .to("#text3", 1, {attr:{transform: 'scale(1)'}});
 
Neither does this work:
 
{attr:{transform: {scale: 2}}}
Link to comment
Share on other sites

A few comments:

  1. The latest version of GSAP has some nifty new features that cause CSS transforms to work properly across browsers. There are all sorts of inconsistencies among browsers, especially related to transform-origin, but as far as I can tell, the latest version delivers works around the various problems in browsers which is something we're really excited about
  2. It looks like you stumbled across a Webkit bug on <text> nodes specifically where the text doesn't visually scale even though things are being applied correctly by GSAP. You'll notice that Firefox does apply the css transform. Weird, I know. Again, this is a browser issue, not GSAP. 
  3. The solution is pretty easy - just wrap your <text> node in a group (<g>) and animate that instead. Seems to work like a charm. 

I'm pondering whether or not it'd be wise to add conditional logic inside CSSPlugin to sense if it's a <text> node and apply things differently, but the major down sides to that are:

  1. When CSS transforms are applied to the attribute rather than the CSS style property, you lose 3D because the SVG spec simply doesn't allow it. So if we apply this "fix" and force <text> to use transform="..." instead of style="transform:...", you forfeit 3D. Since there's an easy solution (wrap <text> in a <g> and animate that), I'm more inclined to advise folks to do that.
  2. Webkit will almost surely fix this "bug" at some point in the near future at which point GSAP's "fix" will be irrelevant, thus the 3D limitation will be annoying/unnecessary. 
  3. More kb

I'm certainly open to being challenged, but at this point I think it's probably wisest to stick with the existing GSAP behavior and use a <g> wrapper fix.

  • Like 2
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...