diff --git a/README.md b/README.md index ff9a115..9997007 100644 --- a/README.md +++ b/README.md @@ -38,4 +38,4 @@ Our current proposals are focused around allowing cross-origin/site prefetching, ## Portals -The [portals](https://github.com/WICG/portals/blob/master/README.md) proposal was one of our earliest efforts in this space. We eventually realized that it's part of a larger constellation of features, and decided to turn our attention to prefetching and prerendering, and make them rock-solid, before we return to portals. Once we're confident in the foundations of prerendering content without a visible portal onto it, we plan to return to the portals specification and rebase it on prerendering. +The [portals](https://github.com/WICG/portals) proposal was one of our earliest efforts in this space. We eventually realized that it's part of a larger constellation of features, and decided to turn our attention to prefetching and prerendering. At this time, portals is not being pursued. diff --git a/prerendering-state.md b/prerendering-state.md index cb377f6..d7134ab 100644 --- a/prerendering-state.md +++ b/prerendering-state.md @@ -37,9 +37,7 @@ ordinary (i.e. non-prerendering) page that's hidden would likely want to "avoid "avoid fetching large video resources". Thus, pages would have to consider both the `hidden` state as well as a re-introduced `prerender` to get the desired behavior. -However, the [portals proposal](https://github.com/WICG/portals/) means that `prerender` isn't mutually exclusive -with `visible` either. In that case, we do want to "run JavaScript animations" and "fetch large resources" since it'll -be visible to the user, despite being in a prerendering browsing context (and all the restrictions that come with that). +However, it's possible for there to be situations where a prerendered page is visible. Examples include the now-defunct [portals](https://github.com/WICG/portals/) proposal, or browser UI modes that prerender pages on hovering over or long-pressing links. In such cases, we do want to "run JavaScript animations" and "fetch large resources" since the page will be visible to the user, despite being in a prerendering browsing context (and all the restrictions that come with that). ### Web-compatibility @@ -74,8 +72,7 @@ partial interface Document { }; ``` -`document.prerendering` returns true if the document's top-level browsing context is a prerendering browsing -context. The `prerenderingchange` event is fired whenever this value changes. +`document.prerendering` returns true if the document's top-level browsing context is a prerendering browsing context. The `prerenderingchange` event is fired whenever this value changes. Currently, it is only ever possible for it to transition from true to false. A state separate from visibility ensures existing visibility-based states are correctly accounted for. It also forces authors to consider their page's behavior in light of prerendering restrictions and non-interactivity and the fact that @@ -85,12 +82,12 @@ a user may not have initiated the page load in the first place. `prerendering` and `visibilityState` are entirely independent and all combinations of states are possible: -| State | `prerendering` | `visibilityState` | -| -------------- | -------------- | ----------------- | -| Foreground Tab | false | 'visible' | -| Background Tab | false | 'hidden' | -| Portal | true | 'visible' | -| Prerender | true | 'hidden' | +| State | `prerendering` | `visibilityState` | +| --------------------------- | -------------- | ----------------- | +| Foreground tab | false | 'visible' | +| Background tab | false | 'hidden' | +| Browser UI page preview | true | 'visible' | +| Speculation rules prerender | true | 'hidden' | ### Relationship to BFCache @@ -103,49 +100,3 @@ visible side-effects and may, in some circumstances, completely freeze a page. I will be shared between prerendering browsing contexts and BFCache implementations; however, we don't anticipate BFCache'd documents to be put into a prerendering browsing context. As such, `document.prerendering` would not reflect a BFCache'd state. The [Page Lifecycle APIs](https://wicg.github.io/page-lifecycle) remain relevant for this case. - -## Open Questions - -### `visibilityState` as a termination signal - -Authors have been [encouraged](https://www.igvita.com/2015/11/20/dont-lose-user-and-app-state-use-page-visibility/) to -switch from `unload` and `beforeunload` events to `visibilityState=='hidden'` as a signal that their page may be -terminated. See also [w3c/PageVisibility#59](https://github.com/w3c/page-visibility/issues/59) for related discussion. - -Entering a `prerendering` state by being put into a portal (via portal predecessor adoption), is likely a point where -such a termination signal should be fired; it is analogous to navigating to a new page. However, this means pages would -now also have to listen for a switch to `prerendering == true`. - -This [background -doc](https://docs.google.com/document/d/1Xzw0k8DgltI2ohapuDKmjRZLv7NVrRFGusW8IBtiCT0/edit#heading=h.acmnp6zdmcik) deals -extensively with this issue. An ideal solution would introduce a new event for this use case, rather than implicitly -tying it to any particular state. In the near term, we don't think this is a critical use case to solve; when portals -develop closer to shipping, we can revisit whether adding such an event is necessary. - -### Relationship to other states - -As noted in the [background -doc](https://docs.google.com/document/d/1Xzw0k8DgltI2ohapuDKmjRZLv7NVrRFGusW8IBtiCT0/edit#heading=h.14z99pd6akf0), there -are other states where it may make sense to report `prerendering` state. For example, a page loading into a mobile -background tab maybe terminated, without notice, before the user ever sees it. Similarly, the live-preview in a mobile app -or tab switcher is a non-interactive preview, reminiscent of a portal. - -Should these states also report `prerendering==true`? Should they use the prerendering browsing context concept? The -answers here aren't clear but this is worth considering. - -### Naming bikeshed - -We've called this state `prerendering` here to make clear the association between it and a prerendering browsing -context. However, this _may_ be misleading in some cases. Portals aren't exactly prerendering in the way most authors -would think about it. Additionally, a portal may enter the prerendering state from a regular context; this feels -unintuitive to call "prerendering". - -We should also consider future use cases. For example, if -[fenced-frames](https://github.com/shivanigithub/fenced-frame/) were to use this special browsing context, does it make -sense to call it "prerendering"? - -The term "interactive" seems appealing as it captures a major difference between prerendering/portals and regular -browsing contexts. However, it would be unintuitive to explain how a background tab is considered "interactive". In -particular, if we want this to solve [w3c/PageVisibility#59](https://github.com/w3c/page-visibility/issues/59) we'd have the -bizarre case that entering the app switcher would make a page non-interactive, then backgrounding it from there would make -it interactive. diff --git a/prerendering.bs b/prerendering.bs index ee0bc74..4cb525b 100644 --- a/prerendering.bs +++ b/prerendering.bs @@ -212,7 +212,10 @@ Every [=prerendering traversable=] has a pre
document.{{Document/prerendering}}
-
Returns true if the page is being presented in a non-interactive "prerendering-like" context. In the future, this would include a visible document in a `` element, both when loaded into it or via predecessor adoption. +
+

Returns true if the page is being presented in a non-interactive prerendering context. + +

The value can change from true to false, which will be accompanied by the {{Document}} firing a {{Document/prerenderingchange}} event. (It can never then change back to true.)

The prerendering getter steps are to return true if [=this=] has a non-null [=node navigable=] that is a [=prerendering navigable=]; otherwise, false.