Jump to content
Search Community

Simple draggable carousel

darkgr33n test
Moderator Tag

Go to solution Solved by darkgr33n,

Recommended Posts

Hey all,

 

I've run into an issue when porting the code in the attached codepen into my local environment, and i just hoped that someone may recognise the symptoms and have an idea of a fix.

 

The codepen (seems) to work fine, however when I use in my local environment (WordPress) I'm unable to drag the carousel. After some hours of investigation with dev tools, it turns out that, in my local environment, the UL is not calculating the full width of all the LIs and is reporting it at just 1485px (the width of the element in the browser); whereas codepen, is reporting the width of the UL correctly as 7000px. Hence, no drag.

 

If I manually add a specific width to each LI, it does then calculate the width correctly, but there are a lot of pages with different image sizes so doing it manually isn't really possible. From what I've read, the calculated ul width is not based on the content of the li and you have to specify the width of the li elements, but if that is the case I don't understand how codepen is working it out.

 

I just wondered if anyone knows if codepen is doing something behind the scenes that i'm not aware of, or if anyone has experienced anything similar in their coding travels and managed to overcome it somehow ?

 

EDIT: one other point, if i remove the bounding locally, then I can drag the carousel OK, but of course everything disappears as there are no bounds! The UL is still reporting as the width of the browser rather than full width of the content,  but I can drag. With bounding, I can't drag at all.

 

EDIT: one final difference I noted, on codepen, I can see the LI elements get a style of "touch-action: pan-y;" added, however locally, no style is added at all. I'm not sure if this has any affect on anything o.O

 

Thanks!

See the Pen ZEqgymb by darkgr33n (@darkgr33n) on CodePen

Link to comment
Share on other sites

Hi,

 

The only thin I can think of is that something else in your WordPress setup (CSS file) is messing up your particular setup. Maybe try to create custom styles for your ul element with some specific selector for the element and it's parent and try to add them to Wordpress' queue as late as possible. Other option (not elegant really ?) is to add !important to the specific style. But other than that I can't think of a something else that could be causing this.

 

Unfortunately, as you mention, in codepen everything works as expected.

 

Hopefully this helps.

Happy Tweening!

Link to comment
Share on other sites

Thanks for your reply Rodrigo ;)

 

I have tried to use div's rather than ul/li but to no avail. 

I just tried rebuilding on another local setup - a site without WordPress, just good old HTML/PHP - and it works exactly as the codepen version does, so I think you're right: something within WordPress is affecting the calculated width of the UL - or div. I just need to track it down. Or at a push, work out a way within GSAP to get the width of the UL from the LIs and set it, but that feels like a hack.

Back to the investigations. Thanks.

Link to comment
Share on other sites

something else I've just noticed, but on the non-working WordPress version, the UL is given the style: 


"translate: none; rotate: none; scale: none; touch-action: pan-y; cursor: grab; user-select: none; "

 

whereas on the working HTML version with the same JS/CSS/HTML setup, the UL is given the style:


"touch-action: pan-y; cursor: grab; user-select: none;"

 

o.O

Link to comment
Share on other sites

i also noticed when using dev-tools on chrome and properties tab, that on the HTML version clientWidth, offsetWidth and scrollWidth are being shown as 7000px (which is the full width of the content), but on the WordPress version, while scrollWidth is shown as 7000px, both clientWidth and offsetWidth are shown as the width of the visible content. 

as far as I understand it:
offsetWidth: The size of the visual box incuding all borders. 

clientWidth: The visual portion of the box content, not including borders or scroll bars , but includes padding . 

scrollWidth: The size of all of the box's content, including the parts that are currently hidden outside the scrolling area. 

which seems to suggest that the non-working WordPress version is showing correctly, whereas the working HTMl version is not as offsetWidth is showing as the full content including hidden elements.

so I think the question is, by initiating the Draggable.create is there any way to force the offsetWidth ? 

I've tried to set it using JS, but I can only set it up to a maximum of the rendered size. So, for example, if it's rendered as 1116px, i can use JS to set it to anything up to 1116px, but not beyond. 

 

if I set bounds: {left: -innerWidth*3} instead of bounds:".carousel", it lets me drag OK, but of course I can't see the whole carousel as innerWidth is actually the width of the rendered UL, not the width of the full content.

Not sure if i should be using getBoundingClientRect somewhere. so frustrating that it works on codepen and HTML!

 

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