Need Help modifying javascript for Slider navigation.

Hi All,

I have this code which almost works for me. My custom cursors change when clicked but I would like them to respond on hover.
Is it possible to modify this. (i'm new to javascript!)

Code:

---

}).data('royalSlider');
              slider.ev.on('rsSlideClick', function(e, origEvent) {
              var width = jQuery('.royalSlider').data('royalSlider').width;
             
              if (origEvent.pageX < (width/2)) {
                    slider.prev();
                    $('.rsOverflow').css({
                          'cursor': 'url(images/prevg.png), default'
              });
     
                    } else {
                    slider.next();
                    $('.rsOverflow').css({
                          'cursor': 'url(images/nextg.png), default'
                  });
     
                  };
                });
              });

---

Many Thanks in Advance

Mmm, this is probably doable, but I wonder if that's wise. I looked up this script (though familiar with this type of script, I never dealt with this specific slider before). Two things I can tell you right off. The:

Code:

---

slider.ev.on('rsSlideClick', function . . .

---

syntax is not normal javascript. It's something the code's author created to enable specific events to be fired upon the slider. In his wisdom he did not include hover (mouseover/mouseout or the jQuery specific events mouseenter/mouseleave) probably for good reason.

Which brings me to the second thing. When I said, "in his wisdom", I meant that since this slider is already mobile device (where there are no hover events per se) friendly, he saw no reason to introduce that kind of messiness. It's actually a bit worse than that. Touch only devices (mostly mobiles, but also some tablets) will fire the mouseover event on touch start. However, this is only for backwards compatibility and it introduces odd results, as the touch start event most closely resembles a click event. So, whereas a click or touch can be roughly equivalent, both begin and end at the same moment more or less. A hover type event ends when the mouse leaves the designated area. The only way to fire an approximation of that on a touch only device is when touch begins on another area, one not designated. This gets messy and confusing because there could be other events on those, and because the hover event will be continually firing until that happens.

So we have two major issues here:

1) how to detect the hover event to begin with since it's not written into the code.
2) how to gracefully end its execution on devices without a mouse or other pointing device.

These can both probably be done, but it's no simple matter. I would advise just sticking with click unless there is some overwhelming reason why hover would be preferable.

Hi John,

Firstly many thanks for taking the time to look into this for me and for the extended essay detailing the issues involved. Much appreciated as always.

You have raised some interesting points for me to consider. Just to make sure we are on the same page with this I have uploaded a couple of test cases. One is a css/html solution, the other a javascript attempt. Both have some issues (yes I'm a novice) and I’m not sure which way to proceed.

Just to be clear - I don’t want the hover to actually do anything until a click is made. I just want different cursor.png on each side of the page.

So - the css/html

Code:

---

.prev1 {
                        left: 0px;
                        width: 50%;
                        z-index: 22;
                        background: transparent;
                        position: absolute;
                        cursor: url('images/prevg.png') , auto;
                        }
                        .next1 {
                        right: 0px;
                        width: 50%;
                        z-index: 22;
                        background: transparent;
                        position: absolute;
                        cursor: url('images/nextg.png') , auto;
                        }

                                <div class="prev1">
                                        <a class="btn btn-custom btn-large" button id="slider-prev"></a>
                                </div>
                                <div class="next1">
                                        <a class="btn btn-custom btn-large" button id="slider-next"></a>
                                </div>

---

This version works exactly as it should on desktop devices.

The problem is that when a touch device is used the transparent navigation divs get in the way of swipe gestures.

I probably could use media queries to hide these divs and partially get around this however the lines between touch and desktop devices are getting more and more blurred so I’m not sure if this is the answer.
Modernizr could also be a possibility but I have never used it and don’t know how reliable it is. And then there are devices that have both touch and mouse control.


and - the javascript

Code:

---

}).data('royalSlider');
              slider.ev.on('rsSlideClick', function(e, origEvent) {
              var width = jQuery('.royalSlider').data('royalSlider').width;
             
              if (origEvent.pageX < (width/2)) {
                    slider.prev();
                    $('.rsOverflow').css({
                          'cursor': 'url(images/prevg.png), default'
              });
     
                    } else {
                    slider.next();
                    $('.rsOverflow').css({
                          'cursor': 'url(images/nextg.png), default'
                  });
                  };
                });
              });

---

This works perfectly on touch devices and swipes as intended.
It also almost works on desktop.

My theory was that as the cursor would be hidden on touch devices it would not come into play. ie. I don’t need the hover events at all on touch as the swipe will take over.
On desktop I don’t actually want the hover to do anything but change the source of the cursor.png as the user moves across the page. Only when the user clicks will anything happen.

I’m a little confused. Is this still as problematic as you first thought. Is there a way to achieve the look I would like through either of these methods? What would you suggest.
It seems a lot of headache for a little bit of functionality but what can I say - I have a couple of sites I was hoping to do like this and, well for now, I really like it.

Thanks again for checking this out for me.
Cheers

ps. I did ask the people who made the script. I’m not sure how clearly I asked what I wanted. Anyway they referred me to this

http://stackoverflow.com/questions/7...ack-mouse-p...

which I have to say is way out of my league for now!

OK, that seems harmless enough. I would take the one that works (the css/html) and setup a media query in css or use javascript to detect touch to make the "touch device is used the transparent navigation divs get in the way of swipe gestures" (the class="prev1" and class="next1" divs) display none. This won't be perfect because some touch devices also have a mouse or other pointing device, but it's about the best you can do.

Maybe something like (using javascript):

Code:

---

<script type="text/javascript">
jQuery(function($){
        $(document).on('touchstart', function(){$('.prev1, .next1').remove();});
});
</script>

---

Seems to work, except on the first swipe. This might be better:

Code:

---

<script type="text/javascript">
jQuery(function($){
        if(typeof ontouchstart !== 'undefined'){
                $('.prev1, .next1').remove();
        }
});
</script>

---

Still, as I say devices with both touch and mouse or mouse like devices will qualify, but that might not be so bad. Some older type touch only devices might also slip through the cracks.

As for that stack overflow link, it isn't all that complicated, but would suffer from the same issues I mentioned earlier. Those events would still fire on touchstart, and the result would be confusing to touch device users for the same reasons I mentioned previously. The approach I'm suggesting will fail in some cases, but in the vast majority of cases should be acceptable and unambiguous for users. It can even be fine tuned if necessary.

Thanks John,
I think I get it now. Anyway I went for your solution above. Works perfectly as usual.
Thank You for taking the time.

Donation made to IRC. (Did this post help YOU? Show your Support)