metafizzy / flickity

:leaves: Touch, responsive, flickable carousels
https://flickity.metafizzy.co
7.53k stars 602 forks source link

Jump on click #111

Closed tienvooracht closed 9 years ago

tienvooracht commented 9 years ago

Hi,

Giving Flickity a try for my upcoming project, and it's looking pretty good!

However i'm seeing one thing that's kind of odd, when my page is loaded and my Flickity Carousel is initiated - when i click either the left/right nav or a dot the page sometimes jumps aligning the top of my Flickity container to the top of the screen. When it does, i have to click again for the next gallery-cell.

It only does this once (after page load).

Any ideas on how to fix this?

desandro commented 9 years ago

I'm sorry to see you're having trouble with Flickity. Could you provide a reduced test case? See Submitting Issues in the contributing guidelines.

tienvooracht commented 9 years ago

Hi,

I took a look at the guidelines which stated to alter one of the codepen demo's so i checked out: http://codepen.io/desandro/pen/LEagaN and noticed the same behaviour when: the top of the flickity container is beyond the top of the screen/viewport.

Looks like when clicking either the nav or dots the top of the flickity container jumps to the top of the screen/viewport .. as if it was ment to make sure the top of the flickity container is in view.

This only happens once, directly after page load! Once flickity is positioned at the top of the viewport and i start navigating it's smooth sailing from there on.

Also when the top of the flickity container is visible, there is no jumping!

Hope this clarifies, just curious if this is default behaviour or not! :-)

Thanks!

Edit: i checked in both safari and firefox on Yosemite .. same behaviour.

desandro commented 9 years ago

Thanks for explaining. The behavior you are describing is the same as reported in #76

This behavior is actually a feature of keyboard accessibility. By clicking/tapping on a gallery, it adds focus to its element. This will jump the scroll so that element is completely in the viewport.

If this behavior is really bugging you, you can disable it with accessibility: false -- which I don't recommend because accessibility is a wonderful thing.

robd commented 9 years ago

IMO this is a problematic for users because it makes it seem as if the next button (or whatever control they're trying to use) is broken. This was the first thing I saw when I tried to use the demo on http://flickity.metafizzy.co/ - I loaded the page, scrolled down a bit and clicked on one of the dots. The page just scrolled back up. I thought the js hadn't loaded properly and the demo page was broken in my browser. I happened to persist with Flickity despite this initial experience, but I wonder if others have a similar first impression. I wonder how many people are using Flickity unaware that this is happening on their sites.

I think that, even if it is desirable for the page to jump about for accessibility reasons (which I happen to disagree with), it would be good if the dots, next button etc could be made to work. If a user clicks on the next button, I think it is their intention to go to the next slide, not focus on the current slide.

The problem with the workaround of setting accessibility to false is that you then have to add back in the keyboard navigation if you want it, which I think is a very desirable feature.

Of course changing this has to be prioritised against the other bugs / features, but I just wanted to share the impact this issue had on my perception of Flickity.

EugeneDae commented 9 years ago

003

How is this not confusing?! Please listen to @robd

robd commented 9 years ago

@EugeneDae For what it's worth, I ended up using a little known (and old) slider called Peppermint mainly because it supported IE8 much better than flickity, and is only 7.705k minimised.

benbonnet commented 8 years ago

better to be aware of this one !

gerasimvol commented 4 years ago

accessibility: false in slider options solved for me