"it breaks the decade-old system-wide iOS behavior of being able to tap the status bar to scroll to the top of any scrollable view" Wait. I don't know of this feature. For example I attempted to tap my addresss bar on iOS but it just goes to change the address. How do I use this feature?
Kill Google AMP before it kills the web
171–180 of 489 posts
Re: Kill Google AMP before it kills the web
#172Earlier quoted context omitted.
If by "anyone" you mean "my tech savvy friends at google" then yes. I've seen many friends end up on a google-hosted AMP version of a webpage, unable to complete whatever ticket purchase etc they needed because whatever autoAMPifyer the origin site uses produced half broken pages. These users have no idea what AMP is or why the page doesn't work (or that they could have reached the origin site directly if they click…
Conceptually this isn't all that different from having a website that works in browser A but not B due to insufficient testing. Why did they not fix it?
Re: Kill Google AMP before it kills the web
#173Earlier quoted context omitted.
Well, it is Gruber we are talking about. He believes in openness when it suits Apple - AMP outputs standard HTML5 which Safari renders - it does its own scrolling but he doesn't quite like it. Google doesn't 'respect' that closed platform. On that 'crime' Gruber has this to say - "If I had my way, Mobile Safari would refuse to render AMP pages." You might have valid reasons not to use AMP but Gruber's are merely that…
"...it does its own scrolling but he doesn't quite like it." Nothing should be doing its own scrolling. Everything should let the native scroll do its thing. Computers work for me and should work the way I expect. I expect the default native scroll.
Re: Kill Google AMP before it kills the web
#174I do not understand the dislike this community harbors for AMP. I personally really enjoy the system; whenever I'm searching for any type of article on my phone (Android), I prefer AMP pages, because they load faster and are far more responsive than some of their more bloated counterparts.
I think the frustration here is seeing the decay of the open web and the rise of AOL-esque walled gardens in which your Facebooks and your Googles own the access methods, and every other third party is subordinate to them.
These guys at Google are abusing the web in order to prevent you from navigating away from google hosted content (I'm a technical user and it still took me way too long to find that menu in the corner), in much the same way that Facebook apps make it hard to escape their respective walled gardens.
Re: Kill Google AMP before it kills the web
#175> Google has no respect for [iOS Safari]. It’s a deliberate effort by Google to break the open web. I could make the same argument that Apple cripples iOS Safari's implementations of emerging standards that aim to bring the web experience closer to a "native feel" to keep its app store revenue churning: http://caniuse.com/#feat=stream ...but really it's a lot more likely that getting _all_ things right on _all_ platf…
sheer overwhelming difficulty + no incentive = no action
Re: Kill Google AMP before it kills the web
#176In theory* I don't mind the idea of having a more standardised subset web page that has a consistent internal structure and that renders quickly. However, having Google load this structured content and host it on its own platform is a terrible idea. Content should remain on the publisher's site. Putting too much content in one place is dangerous for competition. * In practice there are implementation problems too, e.…
> I don't mind the idea of having a more standardised subset web page We already had this two decades ago: WAP, its contemporaries (i-mode), and its immediate successors (XHTML Mobile Profile).
Re: Kill Google AMP before it kills the web
#177The complaint about AMP's strange UX paradigms is valid: it works very hard to pretend like every AMP article is a standalone website, but it actually behaves like a viewport-wrapping iframe, where Google Search is on the outside and the article is on the inside [1]. But it's not a personal affront to iOS; it's more of an artifact of Google's confusing market strategy and conflicting requirements for AMP's deployment…
Is Apple news more than a feed spec like RSS / is the content hosted by Apple directly, like how AMP pages actually live on google.com?
Re: Kill Google AMP before it kills the web
#178Earlier quoted context omitted.
I wish there was a big red “I know what I'm doing” button on iOS that allowed the user to download and install a binary from a simple web page. But technically, you can download the source and/or write your own code, compile and install on your iOS device without jailbreaking or going through the AppStore. It's a hassle, sure, but doable.
I understand the impulse, but so many security issues happen to people because they're tricked into running things… I can't help but think that this would cause a dramatic rise in the number of security issues on iOS.
Re: Kill Google AMP before it kills the web
#179Re: Kill Google AMP before it kills the web
#180So AMP benefits google because faster page loads = more DFP views (and also more $ for publishers); AMP benefits consumers because JS is not murdering their memory and dataplans. It seems like web developers are the ones that hate it.
Have you been to Daring Fireball? It's one of the fastest loading pages on the whole Internet because it's not crapped up with lots of stuff. Gruber's site is proof you don't need AMP to have fast loads. I honestly don't know this: how exactly are AMP pages monetized? Weren't there articles recently that publishers who went with AMP or Facebook's version saw steep declines in revenue?
I seem to recall that publishers who used the Facebook version saw a decline in revenue, so I think you're right about that point. I don't know about AMP, though.