I2I: amp-story-player #24539
I'm working on an iframe-based way of embedding stories into other documents, starting with #23980. I'm writing up a more fleshed-out proposal in a Google Doc, but can migrate that over to GitHub soon! The proposal will include the ability to swipe between multiple stories, as well as the ability to tap on the last page of one story to jump right into the next.
For quite some time, we've been ideating about rich embedding experiences for stories on publisher's own sites. This issue tries to scope smaller projects that can be composed into the larger initiative.
High-level API Design
There are three primary high-level goals of the API:
As such, we have settled on this API:
Since each represents a story, we can include story-level metadata on the tag, as follows:
Milestone 1: "Simple" iframe embed
Write some simple JS to create a sandboxed iframe and propagate the story's src from the embed API to the iframe. That iframe should be wrapped in a shadow root, to prevent publisher styles from targeting any DOM output by this script (primarily as a means of future-proofing the script to allow it to output arbitrary UI elements outside of the iframe context).
As an optimization, we should load the cache URL for the story (we can hardcode cdn.ampproject.org at first, and allow publishers to configure their AMP cache of choice if the need arises).
Milestone 2: Add embed modes
Add a parameter that publishers can specify in the DOM/JSON configuration that can be passed through to the embedMode fragment parameter, to allow specifying embed modes.
Milestone 3: Switch from plain iframe to open source viewer implementation
The open source viewer implementation handles the messaging API between the viewer and the runtime, including the initial handshake, as well as sending messages. Using this JS API with the iframe implemented in Milestone 1 above will create a minimal AMP viewer.
From a user's perspective, this should be a no-op from Milestone 2.
Milestone 4: Ensure the document is a valid story
By virtue of the fact that it is loaded from the cache, we can be sure that the document is valid AMP. We should also ensure it is valid story (not just valid AMP), by either:
From a user's perspective, this should be a no-op from Milestone 2 and Milestone 3, as long as the document was a valid story.
Milestone 5: Allow prerendering
The open source viewer implementation should already support prerendering, with the
TBD. This milestone would have to expose some type of hook for publishers to indicate that a given URL should be prerendered.
Milestone 6: Allow tapping/swiping to next/previous story
Once prerendering is allowed, we should allow tapping/swiping to the next/previous story.
Both require setting up multiple viewer iframes and prerendering the next story. Swipe events should be handled manually and animate to the next story's iframe, positioned after the current iframe, along the x-axis. To enable tapping to the next story, the viewer should handle the selectDocument request, and inspect its payload to determine whether it should move the previous or next story's iframe into focus.
Milestone 7: Preloading
Native apps have a distinct advantage over web content in that they can preload content when users are in other contexts (e.g. on a list of stories, they can begin preloading the assets for the stories in that list). We can simulate this behavior by including code to either directly prefetch content, or to install a service worker to do the same.
TBD. This milestone would have to expose some type of hook for publishers to indicate that a given URL should have its resources preloaded.