On: Search Results are officially AMP’d

[cramforce]

AMP doesn't implement scrolling in software. It is native GPU accelerated scrolling. iOS does have 2 modes and it might be that AMP hits the one some people don't like.

Edit: Filed https://github.com/ampproject/amphtml/issues/5125 to see if AMP can switch to other GPU scrolling mode.

[MBCook → cramforce]

I'm with touche. Why in the world is AMP telling iOS to do scrolling different from other pages? What's the benefit? Why bother?

[cramforce → MBCook]

Everything scroll related is in CSS. The long explanation is here https://medium.com/@dvoytenko/amp-ios-scrolling-and-position...

[Touche → cramforce]

I'm well aware of how janky position: fixed on mobile. The solution is not to use position: fixed, not to try to "fix" it and make the experience bad.

[untog → MBCook]

IIRC the iOS UIScrollView has a different scroll behaviour when it's inside a UIWebView. So they might have reset that difference.

[Touche → cramforce]

Why does AMP do anything with scrolling at all?

[JohnDotAwesome → Touche]

Knowing where the viewport is relative to the document is pretty valuable; It means that AMP can defer loading potentially sluggish content until the viewport lands on a particular position.

[Touche → JohnDotAwesome]

Sounds like a premature optimization to me. The websites I tried did not have such requirements but the scrolling was just as janky nonetheless.

[stonogo → Touche]

It's not premature optimization. It's optimization for ad revenue; they can charge more if they can prove an advertisement is visible on screen.

[idlewords → Touche]

For surveillance and user tracking.

[cramforce → idlewords]

Even if this would be correct (which it is not), it would only require to observe, not influence scrolling.

[idlewords → cramforce]

Maybe not in version 1. Think bigger, you'll get that promotion!

[cramforce → Touche]

This is just CSS which exists for unrelated reasons.