Closed tienvooracht closed 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.
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.
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.
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.
How is this not confusing?! Please listen to @robd
@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.
better to be aware of this one !
accessibility: false
in slider options solved for me
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?