AMP PREVIEW visibility state
Overview
First step in enabling an auto-play preview mode for AMP stories, as described in #12815.
PREVIEW mode should default to PRERENDER mode in most cases, but must be privacy-preserving. This means any external resource loading must either happen through the serving domain (ex. via cache rewrite of <amp-video> target) or by delaying loading the component entirely if there's no viable substitute (ex. <amp-analytics>).
Auto-play should be addressed separately while utilizing preview mode. This is to separate the set of preview-related concerns (primarily privacy and loading of external resources) from auto-play functionality (which may have more nuanced changes on how components function).
Approach
- Introduce
PREVIEW visibility-state enum. Add previewAllowed method to BaseElement which defaults to returning prerenderAllowed. This change makes the PREVIEW visibility-state available and equivalent to PRERENDER.
- Update
preact/base-element.js (prerenderAllowed), resource.js (prerenderAllowed), scheduler.js (maybeBuild), resource-impl.js (isLayoutAllowed_), and any remaining runtime+test files to handle new state.
- Return
false from previewAllowed for any components which may load external resources, blocking them in preview for now; later, their implementation can be adjusted to handle preview specifically. Non-AMP tags such as <img> will require special handling (ex. cache rewrite) to avoid external resources, which will be the responsibility of the code/page presenting the story preview. An initial pass-through found the following tags requiring external loads, which should be initially disabled in preview:
<amp-analytics>
<amp-audio>
<amp-gist>
<amp-img>
<amp-install-serviceworker>
<amp-list>
<amp-live-list>
<amp-pixel>
<amp-story-360>
<amp-story-auto-analytics>
<amp-story-interactive-binary-poll>
<amp-story-interactive-poll>
<amp-story-interactive-quiz>
<amp-story-interactive-results>
<amp-story-panning-media>
<amp-twitter>
<amp-video>
<image>
<img>
<source>
<svg>
<track>
- Members of
@wg-stories and @wg-components can separately prioritize updating the listed components to support preview visibility. This may include logic for visibility state changes from hidden --> preview --> prerender --> visible.
Milestones:
These steps put us in a place where client code can start to display privacy-previews of stories, which a blocklist of unsupported elements.
@newmuis Does this all seem reasonable? It looks to be fairly straightforward, if I'm not missing too much.
AMP
PREVIEWvisibility stateOverview
First step in enabling an auto-play preview mode for AMP stories, as described in #12815.
PREVIEWmode should default toPRERENDERmode in most cases, but must be privacy-preserving. This means any external resource loading must either happen through the serving domain (ex. via cache rewrite of<amp-video>target) or by delaying loading the component entirely if there's no viable substitute (ex.<amp-analytics>).Auto-play should be addressed separately while utilizing preview mode. This is to separate the set of preview-related concerns (primarily privacy and loading of external resources) from auto-play functionality (which may have more nuanced changes on how components function).
Approach
PREVIEWvisibility-state enum. AddpreviewAllowedmethod toBaseElementwhich defaults to returningprerenderAllowed. This change makes thePREVIEWvisibility-state available and equivalent toPRERENDER.preact/base-element.js(prerenderAllowed),resource.js(prerenderAllowed),scheduler.js(maybeBuild),resource-impl.js(isLayoutAllowed_), and any remaining runtime+test files to handle new state.falsefrompreviewAllowedfor any components which may load external resources, blocking them in preview for now; later, their implementation can be adjusted to handle preview specifically. Non-AMP tags such as<img>will require special handling (ex. cache rewrite) to avoid external resources, which will be the responsibility of the code/page presenting the story preview. An initial pass-through found the following tags requiring external loads, which should be initially disabled in preview:<amp-analytics><amp-audio><amp-gist><amp-img><amp-install-serviceworker><amp-list><amp-live-list><amp-pixel><amp-story-360><amp-story-auto-analytics><amp-story-interactive-binary-poll><amp-story-interactive-poll><amp-story-interactive-quiz><amp-story-interactive-results><amp-story-panning-media><amp-twitter><amp-video><image><img><source><svg><track>@wg-storiesand@wg-componentscan separately prioritize updating the listed components to support preview visibility. This may include logic for visibility state changes from hidden --> preview --> prerender --> visible.Milestones:
previewAllowedtoBaseElementThese steps put us in a place where client code can start to display privacy-previews of stories, which a blocklist of unsupported elements.
@newmuis Does this all seem reasonable? It looks to be fairly straightforward, if I'm not missing too much.