Hacker News Reader

Comment by oneloop | Hacker News Reader

They've had them in Google News for ages. I've been using them for a while, work great (I'm on Android). So well in fact even though I am on the 0.1% of the population that's consciously aware of their tactics, they have already trained me to subconsciously prefer clicking on websites that have their AMP logo, compared to the rest, because I subconsciously know they load much faster.

View on HN

When I first saw it (in the 'News' section of results) I was happy to see it. After clicking 2 or 3 of the links I quickly learned to avoid it and either go to another site or find the non-AMP link in the results below.

I really wish sites (AMP isn't the only thing to do this) would stop deciding they know how to implement scrolling better than my browser/OS does it. Here's a hint: YOU DON'T. Let the user have what they're used to. Sudden behavior changes for tenuous-at-best benefits ("It scrolls faster!") are obnoxious.

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.

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?

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

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.

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

Why does AMP do anything with scrolling at all?

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.

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

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.

For surveillance and user tracking.

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

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

This is just CSS which exists for unrelated reasons.

It would be so nice if there was a knob to disable whatever JavaScript API (or part thereof) enables this yet keep everything else.

Of course, it would have to work seamlessly without breaking anything, so it might be asking a little much.

Unfortunately, blocking that API (listening for 'wheel' events) will entirely break large portions of many sites -- any element where they've manually implemented the scrollbar or have fancy stuff or whatever won't work. I tried writing a Greasemonkey script that killed smooth scrolling, but it broke way too many sites.

One thing that does work though, at least in a lot of cases, is using an adblocker to block the URLs of common smooth scroll scripts. My adblock filter rules are in a comment in this gist if you want them (actually, this gist is my aforementioned Greasemonkey script): https://gist.github.com/oxguy3/ebd9fe692518c7f7a1e9

Wow, you've complained about scrolling in a lot of different threads on this page.

so? That just means he's right multiple times

They do not work as well on iOS. Two examples of this are "scroll to top" by tapping the title bar is completely broken under AMP. The other is that Safari Reader is mostly broken under AMP. That said, the experience with super fast, virtually instant loads, is great, and I think these are definitely kinks that can be worked out.

I'm just confused why they made it through to consumer release without someone else questioning them. These are major features of the most popular browser on [one of the two] most popular mobile OS that Google is choosing to break.

Edit: Added "[one of the two]"

> "scroll to top" by tapping the title bar is completely broken

This is because the scrolling is in a container rather than the body. It's a tough problem on many mobile pages using sliding drawers for example, which rely on overflow based scrolling. There's no event, that I'm aware of, for a web app to listen for for tapping that UI element on iOS.

Ultimately, it's a non-standard convenience introduced on iOS only. Maybe someone else here has solved this :)

I'm not sure how this is non-standard.

On iOS, there are various conventions that apps generally follow. On a list item you can swipe from right-to-left to bring up a Delete option. On a list of stuff you can tap at the top of the screen to scroll to the top. These are standard things in the iOS ecosystem.

A good parallel outside of iOS would be the pervasive use of right-click to bring up a context menu in Windows or the convention of having "--help" show help text in Linux.

Non-standard with respect to what? It's used in every Apple app, as well as tons of third party apps — Facebook, Instagram, and Gmail to name a few.

" the most popular mobile OS "

iOS at 23% and falling...

http://bgr.com/2016/06/02/apples-mobile-market-share-sees-bi...

A cursory look at those stats should tell you they're bogus. Going from 32% to 23% market share (about a 30% decline) in two months is not even remotely likely.

I just edited it to say one of the two most popular to avoid going there. I don't think it changes my point.

Doesn't it? I think it straight up answers your question.

The point I was trying to make was that iOS, and Safari on iOS, has a massive, massive user base. Throwing #1 vs #2 into the mix is distracting from that point.

Reply on news.ycombinator.com