I noticed a strange bug in iOS 10 with the CSS scroll-snap properties.
Here's my css:
#springBoard{
height: 100%;
width: 100%;
font-size: 0px;
white-space: nowrap;
overflow: scroll;
-webkit-overflow-scrolling: touch;
-webkit-scroll-snap-type: mandatory;
-webkit-scroll-snap-points-x: repeat(100%);
}
section{
display: inline-block;
width: 100%;
height: 100%;
vertical-align: top;
font-size: 16px;
}
If I programmatically scroll to a snap-point and then change the content inside the scroll-snap container, the nav snaps back to the first snap-point.
// Programatically scroll the scroll-snap container
$("#springBoard")[0].scrollLeft = 320
It doesn't seem to be related to the way I trigger the scrolling. All these scrolling methods produce the same result:
$("#springBoard")[0].scrollLeft = 320
$("#springBoard").animate({scrollLeft: 320}, 1)
$("#springBoard > section:eq(1)")[0].scrollIntoView()
window.location.hash = "sectionId"
- The bug doesn't happen when scrolling manually (See @maxime's comment below).
- It's present since version 10.3.2 of iOS.
- Don't know if it's fixed in iOS 11.
I spent a couple of days trying to solve the issue but without success so far.
Here's a stripped-down example of my nav: Codepen Demo
stupid bug?
Change Content
button it stays at the same snap point. It is only if i click on the button without having done any scrolling that there is the bug. – Pygmywindow.scrollTo(0, 0); //or some variant
– Brandwein