3 ms·

Is that really Apple's stance? I find the scrolling to be the #1 reason why I bounce from AMP pages. I would hate for them to make this a system wide behavior.

cramforce 9y ago
Yeah, I don't care either way. But Safari should have the SAME scroll inertia for every scroll context and ideally it is the same as used for native apps.
- askafriend 9y ago
  Yep, I agree with you. It should definitely be consistent across the board. Oh well, maybe I'll get used to the inertia scrolling. I'll give it a shot when they make the system-wide change. For now though, the different scrolling experience on AMP (and some other pages) is jarring to the point that I don't even bother and I just bounce.
- dzhiurgis 9y ago
  It feels like putting inertia control options in a browser was a big mistake in first place.
  - cramforce 9y ago
    There are no such controls. There are just different places where one can scroll. All other browsers (as far as I know, and this includes Safari on desktop) make all of these the same, but mobile Safari chose to make them different.
om2 9y ago
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 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.
- alanh 9y ago
  Thank you for sharing this information!
- MBCook 9y ago
  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.
- cramforce 9y ago
  Is there a way how the behavior could be implemented in software to match default?

cramforce 9y ago

Yeah, I don't care either way. But Safari should have the SAME scroll inertia for every scroll context and ideally it is the same as used for native apps.

askafriend 9y ago
Yep, I agree with you. It should definitely be consistent across the board. Oh well, maybe I'll get used to the inertia scrolling. I'll give it a shot when they make the system-wide change. For now though, the different scrolling experience on AMP (and some other pages) is jarring to the point that I don't even bother and I just bounce.
dzhiurgis 9y ago
It feels like putting inertia control options in a browser was a big mistake in first place.
- cramforce 9y ago
  There are no such controls. There are just different places where one can scroll. All other browsers (as far as I know, and this includes Safari on desktop) make all of these the same, but mobile Safari chose to make them different.

om2 9y ago

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 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.

alanh 9y ago
Thank you for sharing this information!
MBCook 9y ago
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.
cramforce 9y ago
Is there a way how the behavior could be implemented in software to match default?