Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FR: AMP components without AMP runtime #15583

Closed
westonruter opened this issue May 25, 2018 · 12 comments

Comments

@westonruter
Copy link
Member

commented May 25, 2018

In the AMP plugin for WordPress we've been introducing Gutenberg blocks for the various AMP components that make sense in content. For example:

Leaving aside the issue of AMP components not being previewable inside of Gutenberg's React-based editor UI (due to the component lifecycle not being exposed for React components to interface with), these AMP-specific blocks are working well when served on the site's frontend when being served on AMP pages. However, the plugin supports a paired mode where the same content can be served on AMP and non-AMP pages alike. This naturally causes a problem when there AMP markup saved as the source of truth: on non-AMP pages the elements don't render at all.

In ampproject/amp-wp#1151 (comment) we made it so that when content is being rendered on the non-AMP frontend and this content contains AMP markup, that the required component script(s) and the AMP runtime will be added to the page. This ensures that the AMP components render (mostly) as expected. There is one big caveat here, however: the AMP runtime is trying to take control over the entire page even when the page is not being served as AMP. This is particularly observable when attempting to submit a POST form in the non-AMP document with the AMP runtime loaded:

image

  • Only XHR based (via action-xhr attribute) submissions are support for POST requests.
  • action attribute is invalid for method=POST: form
  • Uncaught Error: Only XHR based (via action-xhr attribute) submissions are support for POST requests. form​​​

It would be great if the runtime was able to detect if the page as a whole is not being served as AMP and then limit the degree to which it tries to take over the page. This would facilitate AMP to be used as a reusable component library.

I suggest that the AMP runtime detect whether it is being served in an AMP document specifically by checking for whether head > style[amp-boilerplate] is in the page, as opposed to looking for the whether the html[amp] attribute is present. The reason here is that our plan for gracefully dealing with AMP violations on native/canonical AMP sites in WordPress is to just remove the amp attribute from the root to prevent the Google Search Console from complaining about AMP validation errors when WordPress plugin is already informing the user about them (and they may have acknowledged them). Alternatively, maybe there is a more explicit way to inform the runtime that it is being run in a mixed/dirty mode.

@amedina

This comment has been minimized.

Copy link
Member

commented May 25, 2018

@aghassemi This would be a superb way to leverage AMP as a components library in the WordPress ecosystem and elsewhere.

@QES

This comment has been minimized.

Copy link

commented May 25, 2018

Hi - I think this is a super thing all around - the AMP components are a great toolkit of supported elements that do certain functions.

I am already doing this on my site to some extent - as someone who doesn't like to programme it allows me to deploy tools just by loading the AMP components onto my standard page.

This makes the conversion from desktop to AMP even easier as the dropped in elements are already AMP compliant and don't need to be converted.

@newmuis

This comment has been minimized.

Copy link
Contributor

commented May 25, 2018

FWIW, it would also benefit building CMSes or editor tools for amp-story to be able to preview the <amp-story>, <amp-story-page>, <amp-story-grid-layer> components, etc.

@jpettitt

This comment has been minimized.

Copy link
Contributor

commented May 26, 2018

@rudygalfi

This comment has been minimized.

Copy link
Contributor

commented May 29, 2018

@cramforce

This comment has been minimized.

Copy link
Member

commented Jun 12, 2018

@cramforce

This comment has been minimized.

Copy link
Member

commented Jul 2, 2018

I just wanted to follow up on this. Would it makes sense to set up some dedicated time for this topic to discuss on hangouts?
CC @pbakaus @amedina

@ericlindley-g

This comment has been minimized.

Copy link
Collaborator

commented Jul 3, 2018

+1 I just commented on a related thread before seeing this. I'll set up a strawman time to discuss on hangouts

@westonruter

This comment has been minimized.

Copy link
Member Author

commented Jul 9, 2018

FWIW, it would also benefit building CMSes or editor tools for amp-story to be able to preview the <amp-story>, <amp-story-page>, <amp-story-grid-layer> components, etc.

@newmuis Yes, this is also needed for implementing an AMP Story editor in WordPress's new block-based editor (Gutenberg): ampproject/amp-wp#968.

@choumx

This comment has been minimized.

Copy link
Contributor

commented Jan 8, 2019

Combining the FR #17548 with this one. They are two facets of a related topic:

  1. Make AMP components function independently without the AMP runtime, e.g. in React.
  2. Expose a standard API in AMP components that other frameworks can invoke, e.g. lifecycle callbacks.
@ampprojectbot

This comment has been minimized.

Copy link
Collaborator

commented Jan 24, 2019

This is a high priority issue but it hasn't been updated in awhile. Do you have any updates?

@choumx

This comment has been minimized.

Copy link
Contributor

commented Jun 25, 2019

The forms issue in OP was fixed in #16761. Deduping this with master feature: #20456

@choumx choumx closed this Jun 25, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.