The forums ran from 2008-2020 and are now closed and viewable here as an archive.

Home Forums JavaScript Horizontal drag scrolling

  • This topic is empty.
Viewing 15 posts - 31 through 45 (of 51 total)
  • Author
  • #206420

    @Shikkediel, that seems to scroll on iPad but not when you click on the anchor/image/text. Just when you find a gap as before.

    The number of elements would change so it would need to be calculated with javascript. But I was thinking of trying a static version with a set number of items to see if I could get the mobile/responsiveness working first. So I could set the width of the container in the CSS for mobile/tablet/desktop as I would know how many items there were.

    So the javascript would just need the layout to be draggable and also the default click event not to work after a drag had been initiated – sorry if this isn’t clear.

    But it’s fine if you don’t think it’d make any difference?


    scroll on iPad

    Horizontally, right? Maybe we could call that ‘drag’ and reserve ‘scroll’ for any vertical shift. Getting a bit confused…

    Could you maybe try to explain once more, possibly also how it is different from desktop? I’d have to theoretically figure out what’s going on since I don’t have an iPad.


    Haha I know what you mean, sorry! Yeah I’ll refer to drag for horizontal and scroll for vertical.

    Based off this example:

    I’ll list issues I can see so we can break it down and look at them 1 by 1. Some of them we don’t need to worry about now but I figured best to document.

    • iPad drag doesn’t work if you touch/drag on figure/a/img/text, only if you find a gap

    Other things, not sure if they’re related:

    • Anchors don’t fire on click?
    • If you drag and cursor goes out of the browser window, the drag ‘sticks’ when you re-enter window.
    • On resizing, the layout jumps back to start. 1st item aligned to left?

    Most of them I think are small quirks I noticed but I thought it’s not a bad idea to document them for reference.

    Also need to only load script when screen width is above 480px. When screen height is above 600px, 2 rows are shown. When height is below 600px only 1 is shown.

    Hope that makes sense! Sorry again!


    Okay, it’s dawning on me now. Lol. The first and second issue must be related. I’m gonna have to have a good brainstorm about that and maybe make a temporary page outside of Codepen to see what happens on Android. Can’t imagine it’s something that only occurs on iOS.

    Third one is an easy fix, I’ll add a blur event to cancel the drag. And fourth was intentionally coded like that to prevent any odd positioning on resize. It is still missing the finishing touch mentioned earlier…

    I’m thinking for conditionally loading the script an Ajax call might be best suited. But I’ll have a look at the main (touch) issue first.


    Great, if you want I can message you my email address if you want to show any hosted examples with URL’s you don’t want on the form?

    Yeah I know we were looking at the conditional stuff/resizing at the end. I’m not sure if window.matchMedia and mediaQueryList will be any use for that?

    I gave it ago using:

        if ( $(window).width() > 480) {     
            //Add your javascript for large screens here 
        else {
            //Add your javascript for small screens here

    But it doesn’t react on resize.

    Thanks again!


    That would be the idea indeed. I haven’t found any advantage of matchMedia over a $(window).width(), it doesn’t make the code any shorter and if I’m not mistaken it will return dimensions that have the scrollbars included like with normal media queries. For me that’s a decisive drawback.

    Thinking about it though, I’m not so sure an extra request (loading the script conditionally) is very necessary. A large script might make a difference but with this minor amount of code I’d just incorporate any queries inside it. Making the conditional loading dependent on resizing may overcomplicate as well.

    No worries about any temporary URLs, it shouldn’t be a big deal when a link ends up being dead with all the pens here…

    One question – is it also the complete figure that isn’t draggable or possibly just everything that is inside a?


    Okay, this was breaking the script on Android :

    if (requestAnimationFrame) var neoteric = true;

    So that’s now changed into :

    if (window.requestAnimationFrame) var neoteric = true;

    But my phone doesn’t support the feature so I’m not sure it’s the same cause as the issue you mentioned (good to know at least, I’ll need to update a few scripts). Might depend on the OS of the iPad :

    Or maybe Apple takes a stricter approach to checking for support. Hope that solved it in any case.

    Adding a blur event to cancel dragging didn’t work on Chrome or Opera so made that a mouseleave. No need for a link to the test page, I think. Here’s another pen :

    Let me know if that fixed most of it…


    When I first checked the CodePen on iPad it wouldn’t scroll …but I created a static html page with your code ( and on iPad it drags and links seem clickable! The blur event you added looks to of fixed the drag ‘sticking’ when the cursor leaves the viewport too! Lots and lots of progress! :D

    I guess this must be something to do with how CodePen handles the code. Also checked on iPhone, obviously we’ve not done the responsive-ness of it yet but that was draggable as well so great job! I guess that’s the main part of this broken now and hopefully just into the finishing touches.

    I know we’ve mentioned it before but what are your thoughts on momentum scrolling on iOS devices? I’m not sure how we’d go about re-enabling it, do you think a 3rd party plug-in might be the best way and only run it on mobile/tablets?

    You said on resizing, the layout jumps back to the 1st item aligned to intentionally. One thing I just noticed using an iPad was if I was using the tablet in portrait view (for example) and then rotated to landscape, the content resets to the left. I think it’d be good to keep the place I was looking at in view from a usability point of view – but if this is a real pain in the *** to do, I think it’s fine to leave it how it is! :)

    Thanks again @Shikkediel, great, great job, I really appreciate this!


    Glad that ended up getting solved, I doubted it a bit because what you described didn’t exactly match what I came across. But having it working on Android 2.3, I couldn’t think of anything that would be different on iOS. It’ll be interesting to know what is happening with Codepen though.

    When it comes to vertical scrolling, I think the best thing would be to keep the default behaviour enabled. If it’s not interfering with the draggable somehow of course (but I don’t think it will). You could remove this line and try it out :

    e.preventDefault(); <---
    .find('a').on(press, function() {

    If that’s creating some new issue, a next step could be to implement another bit of script that’ll turn a vertical touchmove into a scrollTop().

    The only ‘conflict’ on resize I can think of is when you’re in portrait mode and fully dragged to the left and then change rotation. The element will have more offset that way than it’s supposed to. But it shouldn’t be too difficult to add a tweak for that (I’ll have a look)…

    Good practice. B-D


    Sorry, I think I did it again! I was referring to a horizontal momentum drag on iOS devices, if that makes sense?

    Vertically scrolling, yeah I agree the default behaviour should stay. So when you vertically (touch) scroll down the page on mobile devices it uses the native OS default?

    With regards to the orientation change. I don’t actually think it matters too much if the position resets to the left edge. I don’t think it’s that important for tablets but think it’d be nice on desktop if you resized the browser and didn’t do it – for example, if you’d scrolled all the way to the end, then resized the browser slightly it could be frustrating when it jumped back to start. But that said it’s probably not a big issue!


    horizontal momentum drag on iOS devices

    This should be possible but not without having a scrollbar. You wouldn’t even need the script then :

    Blog link

    So when you vertically (touch) scroll down the page on mobile devices it uses the native OS default?

    Yes but only on body. Any other scrollable element would need the CSS in the link. And overflow can’t be hidden.

    Taking it to the next level would be to add some inertia dragging. And making it ‘infinite’ instead of back and forth.

    [Nonchalant whistling]


    I think the scroll bar would be fine for iOS, it only shows on touch anyways and this would probably make things easier in general?

    So we wouldn’t need any script for mobile and for tablets we’d only need the script that calculates the width and sets it on .project-index and the OS + CSS would handle the rest?

    Interested to know how this would work on Android for example, would Android just use its native scrolling feature as well?

    Is it possible to specify script to only run on desktop – or prevent it from running on other devices?


    Looks like applying momentum scrolling is supported from iOS 5 and Android 4.1 on. So that’s pretty good support by now.

    It doesn’t sound like a bad idea, maybe we could reintroduce that default setting I ripped out earlier? I’m thinking that was a circumstantial glitch and that it ought to work on a separate page.

    Only checking for screen size wouldn’t be enough for this though (there’s an overlap with desktop and tablets) but combined with a check for touch support I see no reason for it not to work for the majority of cases. But there’s trouble to expect with a desktop machine that has a trackpad because you can’t predict if the user will use touch or mouse. I’ll have to contemplate a bit on if this could be reasonably solved.

    I’ve been playing with the idea to create an inertia dragging script before but that might take a while to complete (so that’s really not too relevant). The user would probably appreciate the native behaviour anyway though because it’ll save battery usage when executing less script.


    Yeah I think checking for touch support would be more than sufficient – it might not be ideal if it responds differently on a trackpad but at least the content will still be accessible! And this would save a lot of headaches on mobile/tablet scenarios I’m guessing!

    Just send you a message on twitter by the way!


    Yeah I think checking for touch support would be more than sufficient – it might not be ideal if it responds differently on a trackpad but at least the content will still be accessible! And this would save a lot of headaches on mobile/tablet scenarios I’m guessing!

    Just send you a message on twitter by the way!

Viewing 15 posts - 31 through 45 (of 51 total)
  • The forum ‘JavaScript’ is closed to new topics and replies.