Document document.prerendering always going from true to false

Also change how portals are mentioned since that proposal is no longer being pursued.

Closes #50.

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.

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.

prerendering.bs

@@ -212,7 +212,10 @@ Every [=prerendering traversable=] has a <dfn for="prerendering traversable">pre
 <dl class="domintro">
   <dt><code><var ignore>document</var>.{{Document/prerendering}}</code></dt>
 
-  <dd>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 `<portal>` element, both when loaded into it or via predecessor adoption.
+  <dd>
+    <p>Returns true if the page is being presented in a non-interactive prerendering context.
+
+    <p>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.)
 </dl>
 
 The <dfn attribute for="Document">prerendering</dfn> getter steps are to return true if [=this=] has a non-null [=node navigable=] that is a [=prerendering navigable=]; otherwise, false.