Draggable AutoScroll issue

[thartwell]

Hi fellas, got an interesting problem I'm trying to solve.

 

When the draggable has other elements inside it that extend outside of the draggable’s bounds, and autoscroll is enabled, it will increase the dimensions of the container larger than it should be.

 

I borrowed your codepen so you could see the problem as easily as possible, I hope that's okay. You can repro the issue by dragging the box to the far right. Once it hits the bounds the first time, it will artificially increase the container to accommodate the pusedo div.

 

Since the scrollWidth and calculations are all read only, and the problem is not really related to GSAP but with the browser calculations, I'm struggling to find a solution.

I realize the easiest method would be to make the entire shape the draggable, but for what I'm using it for, that's not a good option. It's a magnifying glass you drag around, so the handle is not in the calculations for more accurate targeting, if that makes sense.

Thanks for all your help!

See the Pen jOzKpVW by thartwell (@thartwell) on CodePen

[iDad5]

The ::after element isn't counting to the dimensions of the box element, as it is positioned absolutely and therefore out of the elements flow. 
It might be possible for Jack aka @GreenSock to apply some of his magic to try to consider absolutely positioned ::after and ::before (etc...) elements if the dragged element is a display parent - but that seems tough as accessing pseudo-elements wit JavaScript is near impossible... (not to mention shadow DOM et al...)
So there are several feasible directions I'd see:

- Changing the ::after element to a 'real' (JS-generated) element that count to the elements dimensions.
- Changing the overflow (and scroll- ?) properties of the container so that the problem isn't visible. 
 -Moving the magnifying-handle with script outside the container context with observer and maybe quickSetter()...

 

 

there might be more...

[thartwell]

Thanks for the response!

I positioned it absolutely on purpose, specifically so that it would be out of the flow. I want it to be able to go offscreen. In my project I don't want the handle included in the dimensions, so that the magnifying glass part has better targeting.

The issue seems to be that although it isn't counted toward the width and height of the box element, it is actually counted towards the scrollWidth and scrollHeight, which causes the scroll container to expand to try and accommodate it. Setting the overflow to hidden on the main box element, as you suggested, would alleviate the issue but would also hide the element I want visible.

In the project I'm working on, I tried a regular div with background image, an image, and finally a pseudo div and they all count towards the scroll dimensions.

[iDad5]

That sounds (somewhat) understandable, as the browser surely knows more about the element's dimensions than JavaScript will tell us. 
In that case probably solution 3 or some variant would be the way I'd go. 

Maybe also a custom-cursor would do the trick (ignoring touch devices for now...)

 

Knowing how 'magnifying' is supposed to work though would likely help in suggestion a solution.

 

[thartwell]

I just edited the demo so that it's maybe a little more clear.

If you look at the variables or the console.log, you can see the width of box_1 is only 150px, and does not take into account the absolutely positioned element. This is by design and how I thought everything would work with the autoscroll.

However, if you look at the scrollwidth of box_1, it's 200px, which is taking the dimensions of the pseudo div into account. On the first drag, the bounds aspect works correctly and you can see in the console that the container's width and scrollwidth are the same (741px).

However, if you try to drag after hitting the bounds on the far right, you can watch the scrollwidth of the container element increase by 50px. This causes extra dead space to be added to the scroll.

I wouldn't think this would happen as I am specifically telling the browser I want the absolutely positioned element to be visible but outside the flow, but that is not the case.

[GreenSock]

From what I can tell, that's behaving exactly as it should (unless I'm misunderstanding something). The browser doesn't ignore that over-hanging position: absolute element when it figures out the scrollable area. That's totally unrelated to GSAP/Draggable. It's just how browsers calculate scrollable area.

[thartwell]

The issue (for my project anyway) is that when the browser increases the scroll area, it creates this dead space, as seen in the screenshot. But then snaps back to the "correct" dimensions at other points where that space is gone. It only appears when you try to drag at the end of the "bounds".

Yes, I figured it was a browser issue and not GSAP, but was hoping / wondering if you could think of a way around it.

[GreenSock]

You want a way to have the element there (and visible) but make the browser act like it's not when it calculates the scrollable area? The only thing I can think of is to wrap your content inside another container <div> that has overflow: hidden. So your scroller stays the same, but it has one child - this new wrapper element that has a fixed width/height and overflow: hidden so that when you drag that child element beyond the bounds, it just crops it. Untested - just an idea. Good luck!

[thartwell]

Thank you both for your help! The extra container turned out to be an easy and simple solve.