Jump to content
Search Community

MInor bugs with SVG

Raynor 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

Hi there guys!

I am a newbie to GSAP - discovered it while searching for universal cross-browser tool to make efficient animations for the web-sites. In short, it's great) I'm planning to use svg a lot, so it's crucial for me how it is handled in GSAP. I delved deeper and did some experimentation, and as a result I came up with what seems to be a bug:

- 3D transform (rotationY, for example) does not work in Firefox, though, in contrast to IE, it is supported in FF.
It took some time until I figured out that with earlier versions of GSAP (back from 1.14.0) everything's working fine. No problems in Chrome as well.

- The next thing that annoys me a little is the necessity to use {transform-origin: "50% 50%"} each time to make svg element rotate around its center; as opposed to what is written in "getting started" guide, it seems that this value is not default for svg elements: their transformation is done around left top corner if {transform-origin: "50% 50%"} is not defined explicitly.

See both cases on Codepen here  .

Thanks!

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

Link to comment
Share on other sites

Thanks, Raynor. Glad to hear you're enjoying GSAP thus far. And thanks for sharing some suggestions for making it even better. 

 

The Firefox thing actually has to do with a bug in Firefox itself that causes it to fail the test for whether or not it correctly renders CSS transforms rather than needing them to be shoved into the "transform" attribute. After applying CSS transforms that affect its size, getBoundingClientRect() doesn't reflect any changes. Frankly, since the SVG spec itself doesn't support 3D transforms and browser support is so flaky for them anyway (Chrome doesn't render transformPerspective, IE refuses to support any kind of 3D on SVG, etc.), it's impossible for us to harmonize 3D support for SVG across browsers. We focused on 2D which we could make work.

 

That being said, I did tweak the upcoming 1.15.1 release to allow Firefox to apply transforms to the style attribute instead of the transform attribute, so it should solve that issue for you. But we can't make 3D work properly across all browsers - it's simply impossible unfortunately. 

 

As for the transform-origin stuff, I don't see any way to resolve that in any kind of performant way because of the way browsers report the current value. Basically, we must ask the browser for the computed style values and it spits back a value that indicates the origin should be at the top left for SVG (assuming the default), but there's no way for us to know for sure if the user set that (via a CSS style) or if it was just defaulted that way. So, for example, if we ran logic that said "if the browser says the origin is in the top left, let's force it to 50% 50%", what if you WANTED it to be in the upper left? You couldn't do it. See what I mean? Other than literally analyzing every style sheet that's affecting that element and searching for a transform-origin value (which would really hurt performance), it's simply impossible. If you've got any other ideas/suggestions, I'm all ears. 

 

If you want to test a preview of TweenMax 1.15.1, you can do so here: https://s3-us-west-2.amazonaws.com/s.cdpn.io/16327/TweenMax-latest-beta.js- that should resolve that Firefox 3D thing for you.

  • Like 1
Link to comment
Share on other sites

Thanks for your help! Yeah, I know that Internet Explorer does not support 3D transforms for svg, nor does it support svg CSS3 animation, but in this sense GSAP stands out with its own animation engine and ability to morph CSS classes, which actually works with svg in IE! And that allows to make svg animations that are crossbrowser-compatible (for the most part).
As for 3D, I think i can live knowing that if won't work in IE, while basic things like Y-rotation works nicely in FF and Chrome (anyway, it's mainly used just for decoration).
So, I'd like to have it keep working in FF (I have some effects in my current project) - no good when it works in CSS3 and doesn't in GSAP, agreed?) I just was surprised that it worked in 1.14 and didn't in 1.15, which made me think that something was accidently broken in new release.

 

Next, as for transform-origin. If I understood your properly, the problem here is that what works for DOM, doesn't work for SVG. With SVG, you cannot rely on what browser is telling you because (I suppose) it will always set transform-origin to the upper left corner of the element, and that's not what we want.
I think what is needed is different method to calculate transform-origin for svg.   Snap.svg for example has transform() method that always sets tr.origin correctly in the center of the element by default.  
I think maybe GSAP could use some kind of Snap getBBox() function to automatically determine svg element coordinates on svg canvas and apply them as default transform-origin value. For example, we can get bounding box for the element with .getBoundingClientRect() and take coordinates from there.

I guess in the vast majority of cases that will fit with what user wants to achieve. If, for some reason, user decides to rotate around left top, he can just enter either {transform-origin: left top} or {transform-origin: 0 0} and it will work (like it actually works now).
If transform-origin is set manually in CSS stylesheet, GSAP should override it.
Just my thoughts, maybe I'm missing something
 

Link to comment
Share on other sites

I don't think we're quite understanding each other on the transform-origin thing. It's not an issue of DOM working and SVG not working. The browser correctly reports where the transform-origin value is. The problem is that it's impossible for me to discern if it's in the upper left corner merely by default or if the user actually WANTS it there, and set it via CSS. 

 

So if I applied the logic you're talking about, it would make it impossible for users to set the origin to the upper left corner via CSS because GSAP would assume that was the default and force it to 50% 50%. 

 

GSAP already uses getBBox() to do all the calculations it needs for plotting things (when it needs to do so). 

 

The only [somewhat] viable option I see here is to always assume that when the browser reports the origin as being the top left, it's the default and we force it to be 50% 50% instead, and then if people want to get around that, they'd need to set transformOrigin directly with GSAP instead of in CSS. I'm not sure that's ideal, though, since it might seem like a bug to folks who wanted it in the upper left. If anyone else wants to weigh in with their opinion, please do. 

Link to comment
Share on other sites

I see your point. The last option that you mentioned is exactly what I was talking about, it just didn't get through to me why you consider this behaviour undesirable. I think the vast majority of people prefer transform-origin in the center (maybe you can do some kind of poll on this matter?), and, if they are already using GSAP, it would be more comfortable to set any other transform-origin they want directly in the tween options, rather then in CSS. I am eager to know what other users think on this matter.

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...