9 ms·
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
by cramforce 9y ago
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 :)
- cramforce 9y agoOn 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.
- deleted 9y ago[deleted]
- jkezfvjnawu 9y agoAwesome, let's hack webkit so that our hack of a product works.
- ehed 9y agoCan you team also work on a way to let people opt-out of Google AMP?
- ghughes 9y agoAre you going to fix this? https://amphtml.files.wordpress.com/2017/02/image1.png https://amphtml.files.wordpress.com/2017/02/image1.png
- MBCook 9y agoThe snark at the end seems very unwarranted.
- cramforce 9y agoSorry, 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.
- MBCook 9y agoI 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.
- Anderkent 9y agoIt's hardly AMP's fault that safari scrolling is inconsistent. Any complaints about that should be aimed at safari, not AMP.
- MBCook 9y agoThe 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.
- deleted 9y ago[deleted]
- askafriend 9y agoIs 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 agoYeah, 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 agoYep, 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 agoIt feels like putting inertia control options in a browser was a big mistake in first place.
- cramforce 9y agoThere 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 agoIn 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.
- freyr 9y agoAnother 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.
- cramforce 9y agoI 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.
- freyr 9y agoGreat. Thank you for submitting the WebKit patch, and sorry for heaping the blame on you guys. Looking forward to the update.
- deleted 9y ago[deleted]
- wanda 9y agoWouldn't this line of CSS: -webkit-overflow-scrolling: touch; have addressed the issue?
- cramforce 9y agoThat line causes the observed behavior. But it improves it over not being present.
- Buge 9y agoWhat are you talking about? Who is Gruber? And there is nothing in the article about scrolling.
- wmf 9y agoThe link was originally https://daringfireball.net/linked/2017/05/20/gilbertson-amp https://daringfireball.net/linked/2017/05/20/gilbertson-amp which complains about scrolling.
- mirthflat83 9y agoI 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.
- niftich 9y agoA 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?print=pretty https://hacker-news.firebaseio.com/v0/item/14385185.json?pri... [2] https://news.ycombinator.com/item?id=14385185 https://news.ycombinator.com/item?id=14385185 [3] https://daringfireball.net/linked/2017/05/20/gilbertson-amp https://daringfireball.net/linked/2017/05/20/gilbertson-amp
- raldi 9y agoPlease 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.
- madeofpalk 9y agoReally? I use that all the time. How else do you get back up to the top of a long list?
- raldi 9y agoI'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.
- cramforce 9y agoWhen scrolling itself is faster (as is currently the plan for iOS) the gesture is needed less, I assume, since one can just fling up.
- fastball 9y agoI actually loved that feature on iOS. I have an Android now and miss it in Chrome.
- jkezfvjnawu 9y agoStop blaming Apple. This is a crappy implementation that doesn't work well cross platform. There're plenty of ways to implement a static navbar that doesn't break mobile safari's scrolling behavior.
- SA500 9y agoHaha- that is hilarious
- corobo 9y agoCan 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
- sscabral 9y agoMaybe 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.
- gassist 9y agoGoogle 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.