| > Advisory Committee has no say in anything that AMP does. Why did you focus on one irrelevant aspect of that document? The document also includes the Technical Steering Committee, a majority of whose members do not work for Google. That doesn't fit your narrative. > In order to compete with it you need to provide nearly all of the same features. In other words, users want it. > There are no bugs in iOS that preclude instant pages. iOS had broken iFrame scrolling for years. If you can implement safe instant loading while working around that iOS bug, let's hear it. > RSS is a web feed.... There is no feed. I was talking about items in the RSS feed as you quoted yourself in an earlier comment and then somehow forgot, but lets ignore this strawmanning and continue. > That has a standard XML format and can be read by anyone: a client app on your phone, a client app on your desktop, a link aggregator that can be built by a half-decent engineer in about two evenings. Additionally, it is trivially discoverable by including a standard meta tag on a page. So exactly the same as AMP. > They are only "instant" when significant effort has been spent setting up an AMP cache so that some or all content is already on the client's browser before the client hits the AMP page. Aside from effort, this is exactly the same as RSS. The additional effort is from doing things that RSS cannot do like monetization, interactivity, analytics, A/B testing, and above the fold optimizations. Cloudflare handles that effort fine. > An AMP cache destroyes the very essence of the web: linking. You will not get the original URL, you will get the cache's URL. Exactly the same as RSS. A link to an RSS reader is a link to the reader's URL, not the original URL. |
Because that irrelevant part was the only one that would give AMP any semblance of being open.
> iOS had broken iFrame scrolling for years. If you can implement safe instant loading while working around that iOS bug, let's hear it.
I advise you learn something for yourself. Several fixes were provided to AMP but they were rejected without discussion.
> Exactly the same as RSS.
Let's see how AMP is "exactly the same as RSS":
- RSS is a feed, AMP is not
- RSS feed is discoverable via a meta tag, AMP pages are not (you have to search in a search engine, or have a cache of pages)
- RSS is a simple format that can be trivially parsed to retrieve data such as: author, publish date, url to original page, description, and content. AMP requires a near-full HTML parser with AMP-specific extensions: AMP is not valid HTML 5, AMP validator will allow some non-valid HTML5. Additionally, AMP relies on custom elements.
- Any and all RSS readers and aggregators link to the original website in a trivial and discoverable way. There's no url hijacking. AMP all but requires AMP Caches to be fast, and AMP Cache design all but requires to display content not at the original link, but at the Cache's URL. For several years the "open" AMP would deny this was a problem and pretended "it was an implementation detail that AMP is not concerned with" and "we will work with browsers on how to present the canonical URL". And even now the largest AMP cache regularly employs dark patterns to prevent users from visiting the canonical URL.
So yeah. I see how AMP is exactly like RSS.