Jump to content
Search Community

is it BUG? with SVG and Draggable

chriswyl 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

I've the <image element inner group id="A" . This group is inner another group id="B"

the group "A" has attribute transform .


 transform="matrix(.997 .0745 -.0745 .997 97 -406)" Draggable FAIL  - this code was produced by Inkscape with optimization save option.


Now when I want apply draggable to Image element, The group "B" is going far far away tranform matrix x and y about 16300px.


When I changed to transform matrix group "A" like showed below ALL is working OK



transform="matrix(0.997, 0.0745, -0.0745, 0.997, 97, -406)" Draggable OK 


Maybe worth to detecting kind matrix deklaration.




Link to comment
Share on other sites

Hello chriswyl,


Try making sure you add the leading zero ( 0 ) before your decimal points ( . ).


The difference between the two transform matrix is the one with the leading zero's is working.


This matrix has no leading zeros, which could cause parsing issues.

  • transform="matrix(.997 .0745 -.0745 .997 97 -406)"

This has the leading zeros and works:

  • transform="matrix(0.997, 0.0745, -0.0745, 0.997, 97, -406)"

I would make sure your transform matrix in your SVG markup or any other values when using JavaScript.. have a leading zero before the decimal point. This prevents that type of issue your seeing. Some modern browsers have a very strict JS parser in the browser. Since it is missing the leading zero it could interpret the dot (decimal point) as an object like in dot notation. Especially when it comes to the transform matrix even though it is considered a string in the transform attribute.


So just as a rule of thumb and best practice in CSS, HTML, or JS.. always add the leading zero before the decimal point. Then you can prevent the JS, CSS, and HTML parser to know the intent.



  • Like 3
Link to comment
Share on other sites



I believe that the issue here is that Draggable is sensing that the circle is bigger than that boundaries you have supplied to the tool, therefore it's enforcing them and not allowing the element to be dragged anywhere.


From a long time Draggable is able to deal with transformed elements, so this could be the case, since I removed the transform in the group tag and Draggable worked without any issues.


Here's a codepen that illustrates how GSAP adjusts to the transformations:

See the Pen KAFow by rhernando (@rhernando) on CodePen


Finally as Jonathan mentions, perhaps GSAP witch doctors could clarify the issue.

  • Like 4
Link to comment
Share on other sites

@chriswyl, thanks for the demo. Very helpful.


@jonathan, great work. Thanks for the assistance.


@rodrigo, great to have you back. love the demo!


We will look into this further and see if there is anything can / needs to be fixed in Draggable.

  • Like 1
Link to comment
Share on other sites

  • 3 weeks later...

Just to clarify, the main issue is that you've got bounds that are rotated at a different angle than the element that they're "enclosing". That exponentially increases the CPU demand for collision detection, thus Draggable doesn't support that. 


To simplify the explanation, imagine a rectangle inside a bounds rectangle (neither rotated). When you start dragging, we could easily calculate a maximum and minimum x/y value and then on every move, check that. If it exceeds it, we can nudge it back to wherever the max/min is. Nice and snappy performance. Now imagine rotating the bounds 45 degrees. Uh oh - now we cannot set max/min values because there are an infinite number of those along each axis. There are ways to figure all that out but it'd require a LOT more processing on every...single...movement. And then if a collision is detected, we'd have to do even more processing to figure out how far to move it "back" so that it's sitting right on the boundary. Given our emphasis on performance in the whole GreenSock toolset, it just didn't seem like a good idea to implement all that expensive logic especially since it's such an uncommon use case. 


You should be able to implement it yourself, actually, by using the "liveSnap" feature, passing it a function that runs whatever logic you want.

  • Like 3
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...