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

With respect to scrolling: We (AMP team) filed a bug with Apple about that (we didn't implement scrolling ourselves, just use a div with overflow). We asked to make the scroll inertia for that case the same as the normal scrolling.

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 :)




Another bug I've noticed is that AMP breaks in-page searching with iOS Safari. If you perform an in-page search, the browser will not scroll to the found instances of the search term on an AMP page. I imagine it's related to the other scrolling issues.

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.


I believe we have a webkit patch pending for this. Definitely on our radar!

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.


Great. Thank you for submitting the WebKit patch, and sorry for heaping the blame on you guys. Looking forward to the update.


On top of this: we currently have a team working to fix webkit bugs that are problematic for AMP. This, of course, will make webkit better for everyone.


Can you team also work on a way to let people opt-out of Google AMP?



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.


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!


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.


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.


It feels like putting inertia control options in a browser was a big mistake in first place.


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.


The snark at the end seems very unwarranted.


Sorry, but there is some irony there. We were as surprised as anyone. I do like the new inertia much better. Allows for much faster scrolling similar to Android.


I don't think there's any irony here. You deployed something that worked horribly on iOS, you didn't offer a way to opt out, and when someone else put in a fix for your terrible UX that just happens to change everything else to the way your stuff currently works you use it to gloat and a guy who pointed out how terrible your UX was.

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.


Well, they deployed normal HTML5, which because of how the page was defined happened to expose a weird interaction in how iOS performed some actions. They thought it was a bug in iOS and treated it as such. Getting called out as assholes for doing what they thought was the right thing (and by someone that was wrong on the facts to boot) probably rankled a bit. Calling out Gruber as both wrong and in addition so wrong that the company he thinks was maligned is actually changing to the behavior he dislikes does come off as a little snide, but given the facts I wouldn't hold it against them. I definitely wouldn't use arrogant to describe it.


They didn't explicitly set the behavior that way, but they deployed it knowing that WAS the behavior. And they didn't bother to change it or give anyone an option to turn it off or do something else making everyone on iOS suffer since they started pushing AMP.

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 don't have an iPhone, so I can't check the actual behavior to see how broken it is. Is it just not fitting the Norms of the platform, or does it really impede usage?

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.


I don't think it was a bug, I think it was an intentional choice by Apple but I don't think it really mattered to most people untill AMP started using it.

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.


> They thought it was a bug in iOS and treated it as such

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.


This is amazing.

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.


>A hypocrite (Gruber, as evidenced in another thread) calls the AMP team hacks who do terrible work

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"?


> When did Gruber call the AMP team hacks?

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


Indeed, that's in alignment with what I had seen. It seems obvious at least to me that the actual character of Gruber's statements and @julianmarq's portrayal of those statements do not agree.


> Are you claiming that all of them are "Apple's bug"?

Let's see:

- find in page: yup, Webkit bug (Google/Chrome uses Blink).

- scrolling behaviour: yup, Safari bug.

Anything else that I missed?


It was an intentional decision, not a bug:

https://news.ycombinator.com/item?id=14386292


> This is semi-accidental.

I.e., "not design decision".


And how would you characterize Google's decision to ship it in this state, knowing that the behavior was broken in iOS Safari?


You don't think there's any irony in the fact that Google noticed that Safari was behaving badly sometimes, and asked Apple to fix it, and Apple said "wow thanks for pointing that out, we're going to make it much more extreme". Google asked for one thing, and because of that was given the exact opposite. That's pretty much the definition of irony.

>a state of affairs or an event that seems deliberately contrary to what one expects and is often amusing as a result.


I wouldn't have expected Apple to speed up the scrolling on everything else if that's what's really happening, but I don't find it amusing.

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.


> As I said another comments though Safari was doing exactly what it was designed to do

Apple seems to disagree with you, though. I would trust Apple to know better what Safari was designed to do.


Snark? I think we're reading two different comments. I think it's fair to share surprise at a response like that from Apple. I would be surprised, too.

It almost feels like you're looking for reasons to be upset and finger-point. I hope that's not the case.


I took their original remark at the end as a snarky comment about Gruber. I didn't read it as being about the way Apple decided to fix things. If that was the intent it was unclear to me.


Sounds like Apple's underinvestment in mobile Safari makes it currently impossible to implement this well in web pages in iOS, and that the AMP team is working with Apple to fix their broken platform. I don't see how this isn't Apple's bug.


Under investment?

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.


Why? What reason do you have for this belief of yours?

Apple's response indicates it was a bug, and nowhere has Apple said "this is a design decision we are now changing".


It's hardly AMP's fault that safari scrolling is inconsistent. Any complaints about that should be aimed at safari, not AMP.


The way Safari does things is not their fault.

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.


> You deployed something that worked horribly on iOS

Except that thing was a bug in Safari. They used perfectly valid plain HTML without any hacks or JS.


It wasn't a bug in Safari, that was simply the way the scrolling behavior was implemented in iframes.

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.


It isn't related to iframes directly. Iframes in mobile Safari are never scrollable. The div thing you suggest would have the same issue. If you are a web developer you likely have built a website that has this issue.


Ah. I mostly do back end work, the front and stuff I do we haven't spent any time on optimizing it for mobile, only desktop browsers. I'm not familiar with the quirks of mobile browsers. I only know the iframes scroll oddly because I've been told that was why AMP pages feel weird on iOS here on hacker news before.


If you haven't done much front-end word, let alone handled quirks of mobile browsers, consider listening to other people on this thread instead of arrogantly pontificating all around.


So because I don't know the intarcacies of mobile web development I don't get to have an opinion on the UX of a website I use every day?

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.


>It was still there choice to deploy using iframes knowing that that was the way it felt.

So you're blaming Google for not writing around an edge case bug that exists only on one platform?


You call someone's work "terrible" (twice) to their face and now you're upset over a little bit of snark?


I didn't like what I saw as their snark. When they replied they didn't apologize for it or even mention it, they just explained that the scrolling behavior was changing again.

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.


nobody wants that. we like the way iOS scrolls and there's no reason for some pages to work different because you are imposing us an unwanted feature we can't disable and makes google impossibile to use. please remove this AMP thing. it's breaking the web - and the scroll is just the minor problem.


Maybe Gruber's comments about AMP's scrolling implementation were hypocritical (or naive, at least), but this isn't the biggest problem by far. Considering that Apple addresses what needs to be fixed in terms of how the web behaves on its browser, there's no reason for me to be unable to search for text on an AMP page or scroll back to the top on I tap the status bar on my phone.

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.


Google needs to kill AMP. Like many other teams in Google they are filled with arrogant people who believes everything Google have to become "standards" and don't give a damn about how they are being arseholes on other platforms.


What are you talking about? Who is Gruber? And there is nothing in the article about scrolling.


A little bit before 2017-05-21T00:52Z [1], moderator sctb updated [2] the submission's URL from the original blog post by John Gruber [3], to that of an article in The Register penned by Scott Gilbertson. Gruber's post quotes Gilbertson, and supports its main premise, but offers its own perspective.

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


The link was originally https://daringfireball.net/linked/2017/05/20/gilbertson-amp which complains about scrolling.


I have to agree with him. AMP's different scrolling behavior in Safari makes me avoid it entirely--it's the same reason why I avoid using Chrome in iOS.


Can you add an option to bypass the AMP version completely? Google search is mostly ruined on mobile because everyone has jumped on the AMP bandwagon


Wouldn't this line of CSS:

    -webkit-overflow-scrolling: touch;
have addressed the issue?


That line causes the observed behavior. But it improves it over not being present.


Haha- that is hilarious


Please don't "fix" the "bug" that disables the "scroll to the top of the page when the user accidentally taps the top of the screen" behavior. I loathe this behavior, have never summoned it intentionally, and can't imagine why anyone would ever want it.


Really? I use that all the time. How else do you get back up to the top of a long list?


I'm not sure I've ever needed to do that in all my life. But about three times a day I accidentally lose my place on a long webpage and there's no Undo.


When scrolling itself is faster (as is currently the plan for iOS) the gesture is needed less, I assume, since one can just fling up.


I actually loved that feature on iOS. I have an Android now and miss it in Chrome.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: