Apple's response was (surprisingly) to make the default scrolling like the overflow scrolling. So, with the next Safari release all pages will scroll like AMP pages. Hope Gruber is happy then :)
Apple's response was (surprisingly) to make the default scrolling like the overflow scrolling. So, with the next Safari release all pages will scroll like AMP pages. Hope Gruber is happy then :)
Please, please fix this. It's impossible to support something that's foisted on us and breaks basic web functionality. If I were cynical, I'd say bugs like this are designed to degrade the web experience on iOS. There's a lot of bad web programming out there, but very few sites manage to break search.
Edit: some detail. Safari sometimes doesn't scroll find results into view when they are in overflowed space. This issue actually affects a large percentage of web pages. Fixing it was very easy, was just an oversight in 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.
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.
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.
Honestly this whole thing (AMP and your comment) come off arrogant as hell to me.
I like the current iOS behavior because it's what I'm used to. I don't find the slower scrolling speed to be an issue at all. But if everything really is going to change then I will probably annoyed me for a while but I'll get used to it.
I'm not complaining that the scrolling behavior on AMP is too fast specifically (although that's how it feels to me), I'm complaining that it's DIFFERENT from everything else. All my muscle memory of how to scroll things is broken on AMP pages and only AMP pages. (I don't care if it's how iframes work, you deployed it anyway)
Once it feels like the rest of the system then it's not really much of an issue anymore. I'll get over my personal preference.
But the snark was totally unnecessary.
They could've just as easily pushed you to a new page which contain the AMP content and wasn't an iframe, thus leaving all the standard feel and gestures working. Instead they choose to go along with what they were doing on android even though it was severely sub optimal on iOS.
I think choosing to do that WAS arrogant.
They made Google significantly harder to use as an iOS user because they didn't care and gave us no option to try and fix it.
I think the "correct" response in a case like this, where the platform owner has a bug and has committed to a fix in the pipeline for delivery, is highly dependent on the problem. Even then, it's possible to make the wrong choice given the information available at the time.
I prefer not to call the actions of a company and a group of people arrogant without more info than present, even if one of those people expressed a less than sympathetic opinion of the problem. I extend the same courtesy to Apple often enough, it would be hypocritical of me not to.
The big problem with that that only exists on iOS is that the 'weight' of the content is much much less than normal web pages. All your muscle memory of how far and how fast to move your finger to get the page to scroll a certain amount is wrong. Instead the page scrolls MUCH faster and further. This would be bad enough except you're still technically on the Google page and as soon as you go back or close the AMP result the scroll speed is what you're used to.
The end result is it's incredibly frustrating and feels "broken".
I understand that Google's preferred solution caused a behavior that is severely sub optimal because of the way Safari currently works. My problem is I think they handled this extremely poorly and forced all iOS users to deal with it for what, over a year?
I'm glad apples fixing it but I don't like the way Google handled it... effectively saying to iOS users "too bad" since they didn't do anything to mitigate it while waiting for Apple's fixed to come through the pipeline.
The majority of end users don't know anything about divs and iframes and don't care whose bug it is. So the question remains-- since they clearly know that this bug exists, why would they ship like this?
Every time I land on an AMP page on my iPhone, the scroll gets out of control and all of a sudden I've unintentionally followed a link to some video that starts playing with sound. It's ridiculously annoying.
A hypocrite (Gruber, as evidenced in another thread) calls the AMP team hacks who do terrible work. Turns out their "terrible work" is actually Apple's bug and the AMP team points this out both to Apple and to Gruber. In your eyes, this makes it all their fault.
When called out on it, you double down by saying that the team is still to blame because they chose not to work around Apple's bug. You basically want Google to be part of Apple's captive audience.
No, seriously, take a step back and consider that this is what you're saying.
I must have missed this. When did Gruber call the AMP team hacks?
> Turns out their "terrible work" is actually Apple's bug and the AMP team points this out both to Apple and to Gruber.
This is flat out disingenuous, unless you're talking about something other than the originally submitted DF article. There were multiple examples of why Gruber thinks AMP sucks. Are you claiming that all of them are "Apple's bug"?
The link of this thread was originally [0].
Although he didn't use the word 'hack' himself, Gruber said:
"Google has no respect for the platform. If I had my way, Mobile Safari would refuse to render AMP pages. It’s a deliberate effort by Google to break the open web."
So he sees them as intentionally sabotaging things.
0: https://daringfireball.net/linked/2017/05/20/gilbertson-amp
Let's see:
- find in page: yup, Webkit bug (Google/Chrome uses Blink).
- scrolling behaviour: yup, Safari bug.
Anything else that I missed?
I.e., "not design decision".
>a state of affairs or an event that seems deliberately contrary to what one expects and is often amusing as a result.
As I said another comments though Safari was doing exactly what it was designed to do (for whatever reason they designed it that way). I don't think this is a bug on Apple's part. It makes sense to harmonize the scrolling behavior, but I don't believe it was unintentional.
Now I understand what someone was talking about when they said this might be ironic. I wasn't even sure what they were referring to. I can't place my finger on why this doesn't seem like irony to me. Maybe it's just not odd enough.
Apple seems to disagree with you, though. I would trust Apple to know better what Safari was designed to do.
It almost feels like you're looking for reasons to be upset and finger-point. I hope that's not the case.
I'm not sure it was a bug, it sounds like it was a design decision. Maybe not in GOOD one, but I doubt it was a true bug.
Apple's response indicates it was a bug, and nowhere has Apple said "this is a design decision we are now changing".
That they chose to ship that way instead of using an alternate implementation that didn't run into the problem ( or was less frustrating or provided an opt out ) was THEIR decision. They're not 100% blameless in this.
Except that thing was a bug in Safari. They used perfectly valid plain HTML without any hacks or JS.
It was still there choice to deploy using iframes knowing that that was the way it felt. They could've use JavaScript to load the contents into a div or simply pushed so far users to a page that had nothing but the AMP content on it.
They left it severely sub optimal and decided that was good enough… making google significantly more annoying to use on iOS than what it was before.
That was the choice they made and stuck too. No options to turn it off, no options to do it a different way; you just get stuck with it.
So my top-of-the-head guess of something that might avoid it based on what I thought the problem was from other HN discussions wasn't right. What a sin.
That doesn't invalidate my experience or frustration as an end user.
So you're blaming Google for not writing around an edge case bug that exists only on one platform?
My second comment was because I thought the original behavior of implementing AMP the way it was and forcing it on users was arrogant and has seriously annoyed the hell out of me since it originally started appearing on iOS. I've literally considered switching search engines to get away from it because it makes using Google that much harder.
Yeah, I called it terrible to their face. Because it frustrates the hell out of me. I've tried finding ways to contact google, I've tweeted at them, I've posted in previous discussions. At no point did anyone ever seem to wake knowledge the problem other than seeing people (who I assume we're not googlers) basically say it's not their fault because that's the way Apple implemented iframes.
Combined that arrogance with what I see as rudeness... and yeah. I said terrible twice. I'm frustrated as hell at this and don't like that the solution will be "it's going to stay there but Apple is going to make it a little bit better for you".
When the scrolling gets fixed? I'm still gonna be annoyed as hell at AMP pages. They break the experience, but now just a little less. Hurray.
I know, those are native platform affordances that the web doesn't need to care directly because iOS is not an open standard. But neither is AMP.
Changing the submission URL is unfortunate, because a lot of the discussion in this thread prior to 2017-05-21T00:52Z pertains as much to Gruber's material as the Register article. Now a lot of this discussion, as you seem to have noticed, appears out of context.
[1] https://hacker-news.firebaseio.com/v0/item/14385185.json?pri... [2] https://news.ycombinator.com/item?id=14385185 [3] https://daringfireball.net/linked/2017/05/20/gilbertson-amp
-webkit-overflow-scrolling: touch;
have addressed the issue?