Horizontal drag scrolling

[grimski]

Top work again @Shikkediel! I’ll have a good look at this later (currently on a train). Those tweaks you’ve made will be invaluable.

With regards to the container width and the height of the viewport I imagine num_row_figures = Math.ceil(num_figures/2), is the key line? So I’ll see if I can keep all the code in 1 block with only this differing for each ‘query’.

I was having a think about the mobile version. I was going to say the width could just be removed but now I see what you mean about momentum scrolling. Unless all the script was contained in a ‘query’ for resolutions 480px and above then it wouldn’t effect mobile at all? Then when the viewport goes below, say, 600px in height Math.ceil(num_figures/2) is applied?

EDIT: Also removed the styling .project-index {top: 50%; margin-top: -200px;} and put it onto the #container so the top row didn’t go off the screen: http://codepen.io/anon/pen/waRVqx

[Shikkediel]

Cheers, I later optimised the script a bit as well…

When it comes to mobile scrolling, the easiest thing would be to remove this line :

.one(release, function(e) {
e.preventDefault();
swipe = false;
$(this).off(move).off(release);
});

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

It’s practically not doing more than disabling text selecting with the mouse (I think) but it is also the cause of preventing default momentum scrolling. Might be worth a try and see what happens (can’t test any pens myself on my not so recent phone).

Having a bit of trouble following the other questions. Maybe it would be easiest to build in a switch – a default setting that can be accessed enabling/disabling the draggable script altogether depending on the earlier resizing function? One other thing that would have to be recalculated is the overflow. And when you really want to add a finishing touch, repositioning the draggable so it stays in place when the orientation is changed (or any other resize action but in practice that would be the only one apart from webnerds resizing the browser window).

I’ll have another look at it in any case.

[grimski]

Sorry for confusing you @Shikkediel! Haha yes I’d be good if it repositioned so it stayed in the correct position when viewport size/orientation is changed – but yes it probably is webnerds like me who check that!

All I meant was if mobile was treated as the ‘default’, so no draggable javascript is called at all. Then the draggable script is only called when the browser width is greater than 600px (for example), which would then display the content in 1 row and be draggable.

Then it could check if the height of the browser was greater than 600px (for example), and if it was, half the container width so 2 rows are displayed.

I know it’s never as simple as I’ve described but I think that’s what I was trying to say …in my head how I was thinking about how it could work. So working from mobile, up. Rather than getting it working for desktop then trying to disable it?

[Shikkediel]

That sounds logical and definitely doable. :-)

I’ll post an update later today, noticed a small error that makes clicking the links not work as well…

[Shikkediel]

Here’s a first draft of that, with an accessible default setting and some resizing stuff (not the finishing touch yet) :

Draggable top element

You can switch it on or off with this ‘media query’ :

if (window_width < 600 || window_height < 200) $.fn.drag.set.active = false;
else $.fn.drag.set.active = true;

I’ve set the height quite low for demonstrational purpose in Codepen. I’ll leave the browser tab to it open so I can possibly still change a few things later on.

[grimski]

Thanks @Shikkediel, I’ll have a prober look at it this afternoon …I sprained my ankle playing football the other night so just getting back into this now haha! I see when the width of the browser is adjusted now, something must be recalculated so the items aren’t cut off?

A flaw in my ‘mobile upwards’ plan I just thought of was on tablets the momentum scrolling wouldn’t work – but I suppose it will be on a larger/wider screen though so it mightn’t be that bigger deal.

[Shikkediel]

sprained my ankle

Oops. ;-)

something must be recalculated

It’s the dimensions of the parent object, inside which the item is dragged. Just making sure the edges are always correct so it can’t be dragged any further than intended (or gets ‘stuck’ when resizing the opposite way)…

[grimski]

Yeah I noticed that, good job fixing it! I’ve noticed swipe doesn’t seem to work on an iPad though, wonder if that’s to do with the momentum scroll.

Do you use Twitter or something like that by the way?

[Shikkediel]

Twitter or something

Apart from forum posting, I’m not much into modern forms of communication (no FB, WA or anything), lol. I do have a Twitter account but am not very active – started it for another (dormant) hobby of mine (RC cars) :

https://twitter.com/TamiyaWeb

The site I made for that needs an update by the way (it’s actually the reason I got into coding and the first thing I made)…

swipe doesn’t seem to work on an iPad

Do you mean a ‘normal’ vertical scroll? Have a look at the second post on the page for that and maybe try removing the e.preventDefault() that’s pointed out there.

[grimski]

Well let me know if you need a hand with your site at all, I’d be happy to help out on any design/front-end stuff if you need a hand!

It doesn’t drag at all, maybe something to do with the resizing function now? Dragging works ok on an iPad in this example (No resizing/momentum scrolling though): http://codepen.io/anon/pen/dowaXe

[Shikkediel]

Thanks for the offer.:-)

I can’t test on iPad myself or think of any specific reason why it would break on that platform. Could you maybe try and remove these lines to see what happens?

if (window_width < 600 || window_height < 200) $.fn.drag.set.active = false;
else $.fn.drag.set.active = true;

That would be the only real suspect not playing nice…
Inside the script itself the default is false so that would have to be changed to true for it to work now (it’s at the bottom) :

$.fn.drag.set = {active: false};

Might also be worth trying to do :

console.log($.fn.drag.set.active)

Just to check if it registers at all.

Recently I did have some unexpected behaviour on Android when mixing ‘normal’ and immediately invoked functions…

[grimski]

When I removed the code

if (window_width < 600 || window_height < 200) $.fn.drag.set.active = false;
else $.fn.drag.set.active = true;

That got the layout to work and it used momentum scrolling? Though the content did cut off when scrolling all the way along to the side.

I got the same results just removing the else $.fn.drag.set.active = true; from the above too.

[grimski]

I was just wondering, what would the code be to just have the layout draggable with the distinction between clicking and dragging?

I guess that would be a fairly stripped down version? And I could just set the width of the container in the CSS, as if I knew the amount of items and how wide it would be. Was thinking would it be best to get it working that way first? Do you think that would work/be worthwhile?

[Shikkediel]

Hmm… your first post make me think that accessing the default value isn’t possible on iOS. I’ll have to contemplate on that (googling hasn’t resulted in any clues so far).

The drag-click distinction doesn’t bloat the code too much, inside the main event this is the only extra line :

if (Math.abs(end-start) > 30) swipe = true;

And the function that handles the click has the advantage of eliminating the 300ms delay that results from a touch :

.find('a').on(press, function() {

    var destination = $(this).attr('href');

    $(this).one(release, function() {
    if (destination && !swipe) window.location = destination;
    $(this).off(release);
    });

}).click(function() {return false});

This part will stay active, even if the draggable itself is disabled. I’d leave it in place as a tiny ‘swift click’ plugin…

Edit – reading back I realise this wasn’t the question exactly.

I would sooner remove the $.fn.drag.set.active option. The element’s draggability could also be controlled with CSS like you describe in the last alinea. When there is no overflow, it will automatically not be draggable anyway.

[Shikkediel]

I was just wondering, what would the code be to just have the layout draggable with the distinction between clicking and dragging?

Stripped out the default setting but left resizing in place :

Link

[Author]

Posts