Hacker News new | past | comments | ask | show | jobs | submit login

In current iOS Safari, webpage scrolling is inconsistent from all other scrolling on the system. This was an intentional decision made long ago. In addition, overflow areas are consistent with the rest of the system, and thus inconsistent with top-level webpage scrolling. This is semi-accidental. In reviewing scroll rates, we concluded that the original reason was no longer a good tradeoff. Thus this change, which removed all the inconsistencies: https://trac.webkit.org/changeset/211197/webkit

Having all scrolling be consistent feels good once you get used to it.

That doesn't necessarily mean it was a good idea for Google's hosted AMP pages to use overflow scroll all along. The inconsistency definitely did feel weird. And the way they do scrolling prevents Safari from auto-hiding its top and bottom bars. I believe all the desired scroll effects could have been achieved without the use of overflow scroll.

Edited to add: the AMP scrolling model also breaks tapping the top of the screen to scroll to top, and this won't be fixed by scroll rate changes.




I figured that the different rates had to be intentional, but I did wonder why. Thanks for the explanation. I remember the checkerboard background on the 3G when you were scrolling too fast, if the speed was faster I mention it would've been way too easy to hit that.

It never occurred to me that Safari page is what the outlier, I just assumed that Safari pages matched the rest of the system and iframes for the thing that we're off.

Maybe this won't be as hard to get used to as I feared.

Thanks again.


Is there a way how the behavior could be implemented in software to match default?


Thank you for sharing this information!




Consider applying for YC's W25 batch! Applications are open till Nov 12.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: