Jump to content
Search Community

GreenSock does not support enlarged clickable areas

cristian.jujea 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. It is an UX best practice for small interaction elements to have a clickable area which is larger than themselves.


This is usually done with transparent drop-shadows in CSS or with transparent filters in SVG.


Having extended a Draggable SVG element with a filter, the "draggable cursor" does not appear if the mouse is over the filter of the element.


I think this is a major flaw of GreenSock - lots of animatable elements to be interacted with need to be small.


It would be nice to have this flaw fixed soon.

Link to comment
Share on other sites

Hi and welcome to the GreenSock forums,


Sorry to hear you are having problems.

I'm not familiar with this technique of applying an SVG filter to make the clickable area of an element bigger. If you can provide a simple demo showing how Draggable is not meeting your expectations we will be happy to investigate further.


You can just fork this super-simple CodePen demo and add your own code: http://codepen.io/GreenSock/pen/JNRPVY?editors=0010




  • Like 2
Link to comment
Share on other sites

Just my two cents worth, but couldn't you just add an additional element to the SVG with a transparent fill?


Say, for example, you have a tiny 10x10 rectangle and want the draggable target to be 60x60. Create another rectangle at that size with a transparent fill, group it with the visible rectangle and create a draggable from the group rather than the original rectangle. That would give you a lot of control over the size of your draggable target.


Happy tweening.


  • Like 3
Link to comment
Share on other sites

This is usually done with transparent drop-shadows in CSS or with transparent filters in SVG.


I don't think so. See where the mouse cursor changes...

See the Pen ?editors=1111 by osublake (@osublake) on CodePen


If you want a bigger hit area, do what PointC said. You should also have a look at this post showing how bounding boxes are calculated, which isn't a flaw of GreenSock. It's how the browser works.



  • Like 4
Link to comment
Share on other sites

Thank you for your replies. I have a simple SVG circle:


<circle id='svg_sliding_circle' cx='12.421875' cy='0.7125' r='0.45' style='fill: #DCDCDC;' filter='url(#f1)' />


which is "raised" by a shadow underneath it:


<filter id="f1" x="0" y="0" width="200%" height="200%">

<feOffset result="offOut" in="SourceAlpha" dx="0.15" dy="0.15" />

<feGaussianBlur result="blurOut" in="offOut" stdDeviation="0.075">

<feBlend in="SourceGraphic" in2="blurOut" mode="normal">



I was expecting for the cursor to be activated upon entering the shadow, as is with CSS box-shadows:



I noticed that if I remove the GreenSock Draggable object from the circle and add to the style of the circle "cursor: pointer; cursor hand", the cursor does not change to a hand shape upon entering the shadow. Obviously, this is not correct behavior. I hope to have some time to look into the SVG specification and see whether this is missing in order to report it to the SVG Working Group.


Nevertheless, until browser vendors fix this, a professional Javascript animation library should have an extendable click area functionality.


I don't think it is ok to have to add a larger transparent element underneath each element which has a shadow. I plan to use SVG extensively in software which has hundreds of web user interfaces. I would find it unacceptable to have to create hundreds of transparent elements in order to extend the clickable area.


Currently, I am evaluating GreenSock on a few user interfaces. I will consider buying it for complex software in 6 to 12 months.


Thank you.

Link to comment
Share on other sites

Sorry to hear about any disappointment. The example you provided is just using a transparent border (it's not the box-shadow that's expanding the hit area). You should be able to do exactly the same thing with the Draggable stuff if you want (a transparent stroke). 


I'm pretty sure this isn't a problem with Draggable/GSAP, but if you can think of a particular "fix" you'd like us to apply, we'll certainly consider it. For example, are you saying that you think Draggable should add transparent borders to its target(s) automatically? Is there any reason you wouldn't just do that yourself when it's desirable? I'm struggling to see why a feature like that should be implemented in the library. I think you're the first person to ever request something like this (though my memory is getting worse as I age, so I could be wrong). If we hear from a lot of people that it's a pain point for them, we'll definitely consider adding something but I wouldn't want to do anything like a filter because those are very CPU-intensive and would hurt performance. 


Let us know if there's anything else we can do to help. 

  • Like 4
Link to comment
Share on other sites

In CSS the inset box-shadow can allow the element to trigger the clickable area since the inset box-shadow will be inside the bounds of the element. Normally box-shadow is rendered outside the bounds of the element. So i don't see any of the modern browsers addressing this since it would be a usability issue, forcing the box-shadow which is just a shadow to be in the bounds of the element. Which is not how it should work, since a shadow is not clickable, only the element casting the shadow is. Just like when you see a shadow casting from a open door, touching the shadow wont close the door, but only touching the door itself. ;)


Only other way is to add your box-shadow to a child of the main clickable element so its non inset border is within the bounds of the main clickable element.


The below CSS3 spec on box-shadow will explain how the spread of the box-shadow goes outside the bounds of elements box model (padding-box), excluding using keyword inset:








  • Like 4
Link to comment
Share on other sites

A user interface element who's clickable area includes the element's shadow can be better interaction.


Upon psyhically being within the shadow of a door and before touching the door knob, the door can interact by providing useful information about what is behind it or what would be the consequences of closing it. In any public service, it would be helpful if the door to that service would inform you before opening if there is a long queue of people waiting inside for that service and how long you would have to wait in the queue.


In industrial software - software that has hundreds or thousands of user interfaces - it is essential for hundreds of the user interface elements to occupy the smallest space possible and to be interactive.


Thus, extendable clickable areas should be fully covered by a professional interactive animation library.

Link to comment
Share on other sites

Hello cristian.jujea,


GSAP can only follow what the browsers allow and what the web spec allows, in this case the CSS spec or even the SVG spec, that is enforced and functions that way within all browsers. All browsers wont even report the bounding box of the element to include the box-shadow or text-shadow spread. So that is not the fault of GSAP, but how all modern browsers function based on the CSS spec and how the browser vendors follow web standards. ;)


If you think that the spec should behave differently, then feel free to contact W3C, WHATWG, who set the standard of behavior and rendering,  as well as the various browser vendors like Apple, Google, and Mozilla who implement it.


They are always welcome to feedback.


  • Like 3
Link to comment
Share on other sites

Hi Cristian,


No one is arguing that elements should not be allowed to have larger clickable areas. We're just saying it is much easier and much more practical for you as the developer to choose and implement the way that works best. In most cases you could just apply a thick transparent border as illustrated in the demo you provided with a single line of css.


There has been plenty of info shared discussing why adding a clickable shadow or filter would not be a good practice for Draggable to implement.


In Draggable we can not assume that a thick border or a newly-injected DOM element is going to work for you. What if the Draggable element already has a border? What if injecting a new element affects the size of the Draggable thing and thus messes up other calculations you are doing? What if you are dragging an SVG element?


With Draggable we put a lot of emphasis on feature parity between SVG and DOM elements.

Notice how well Draggable works with <circle> and <rect> elements: http://codepen.io/GreenSock/pen/MwaJVK?editors=0010

As you evaluate competing tools I'd offer a friendly challenge to recreate that simple demo.


Again, we're totally open to ideas, It's just very difficult to find a solution that functions for both SVG and DOM, performs well, and doesn't bloat the API. 

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