This intent is part of the larger effort to revamp prerendering of web content - the broader intent was sent out in this thread. I'm sending out this more targeted intent to solicit feedback specific to this API.
As part of the above prerendering effort, the web needs an API to know about prerendering states a document may be in. We propose using document.prerendering to expose this state. This will allow pages to react to being in a prerendering state (or <portal> element).
Pages sometimes want to modify behavior when loaded in a context in which the user didn't intentionally navigate and/or the page can't be interacted with yet. For example: deferring ad measurement and analytics or loading large resources like video.
TAG review statusPending
Interoperability and Compatibility
We considered re-using the previously shipped (then unshipped) document.visibilityState == 'prerendering' API and investigated the compatibility risks in the above design doc. To avoid potential compatibility and other issues this proposal introduces a new API that's not tied to visibility. Since it's a new API, we expect the compatibility risk to be low; however, some existing code on the web does check for visibilityState == 'prerendering' and those pages wouldn't pick up the new prerendering state without being updated.
In terms of interop - only WebKit currently supports some form of prerendering but it doesn't expose the state to the page in any way. The usual risk of other vendors not implementing applies.
Gecko: No signalNot yet
WebKit: No signal
Web developers: No signals
Link to entry on the Chrome Platform Statushttps://chromestatus.com/feature/5355965538893824 - This is the broad "prerendering" status entry. document.prerendering doesn't have it's own specific entry since it wouldn't launch as a separate feature.