Early Design Review: document.prerendering

[bokand]

HIQaH! QaH! TAG!

I'm requesting a TAG review of document.prerendering.

We propose introducing a boolean property document.prerendering and associated change event to distinguish prerendering browsing contexts from regular ones for next-generation prerendering on the web, described more broadly at https://github.com/jeremyroman/alternate-loading-modes.

• Explainer¹: prerendering-state. We also have a draft spec. (The spec is more broad but document.prerendering and related concepts are specified in "Prerendering browsing context infrastructure" section)
• Security and Privacy self-review²: prerendering-state-privacy-questionnaire.md
• GitHub repo: https://github.com/jeremyroman/alternate-loading-modes
• Primary contacts:
  • David Bokan (@bokand), Google
• Organization/project driving the design: Google - Chrome Prerendering
• External status/issue trackers for this feature: https://chromestatus.com/feature/5355965538893824

Further details:

• [:heavy_check_mark:] I have reviewed the TAG's API Design Principles
• The group where the incubation/design work on this is being done: WICG (future)
• The group where standardization of this work is intended to be done: WHATWG
• Existing major pieces of multi-stakeholder review or discussion of this design:
  • Nothing substantial in terms of multi-stakeholder reviews, but there's some background on the problems with using pageVisibility for prerendering state in The spec's definition of hidden is unclear and should be updated to better account for mobile use cases w3c/page-visibility#59.
  • I've also discussed with with the WebPerf WG in Bring back support for prerendering page state w3c/page-visibility#69
• Major unresolved issues with or opposition to this design: N/A
• This work is being funded by: Google

You should also know that...

This is a small piece of a large effort to bring back prerendering in a more predictable and standardized way. The entirety of the prerendering feature is a very large body of work so we thought it be good to separate out parts of it, where it makes sense, for ease of review. This feature would only ship as part of a larger launch of a new prerendering mode.

Also, old versions of prerendering used a special value of the document.visibilityState API for this purpose, but it has since been unshipped and removed from the spec. We've considered whether to bring that back but believe it had some shortcomings (noted in w3c/page-visibility#59) and would be better addressed by an API not tied to visibility.

We'd prefer the TAG provide feedback as:

💬 leave review feedback as a comment in this issue and @-notify @bokand

[plinss]

Is the change from prerendering==true to prerendering==false a one-time change? Or can a document go from prerendering==true back to prerendering false?

[plinss]

I'm also concerned with the prerendering state being a boolean. What's the possibility of there being other variants of prerendering state in the future? An enum would be more extensible.

[plinss]

I'm also concerned with adding more properties to document. It may be useful to consider making a rendering state (or somesuch) object that collects this and other (future) similar properties.

[bokand]

Hi, thank you for the responses and sorry for the delay - I've been OOO for the last two weeks.

Is the change from prerendering==true to prerendering==false a one-time change? Or can a document go from prerendering==true back to prerendering false?

Assuming you mean "can a document go from prerendering==false to prerendering==true" - yes, that is a potential case that comes from the portals proposal. In that proposal, on navigation, the initial page can be "adopted" into a portal on the destination page. In that case, we would want to set document.prerendering == true.

I'm also concerned with the prerendering state being a boolean. What's the possibility of there being other variants of prerendering state in the future? An enum would be more extensible.

I'm somewhat weary of using an enum given the experience with document.visibilityState. It seems that in practice, an enum that's semantically a bool will cause authors to write code like:

if (document.state == 'prerendering')
  doPrerender();
else
  doRegular();

Which will break when a new enum is introduced. Given we don't currently anticipate anything like this and, should it come up, seems like it'd be more appropriate as additional information on something like a renderingState object as proposed below, a bool seems preferable to me.

I'm also concerned with adding more properties to document. It may be useful to consider making a rendering state (or somesuch) object that collects this and other (future) similar properties.

That sounds reasonable to me. My only worry is there aren't additional such properties and it ends up being an object with a single property. Would it make sense to move document.visibilityState into that as well (and any other related properties, do we know of more?) and then spec document.visibilityState to be a shorthand for document.renderingState.visibilityState?

I don't know...it seems like a overkill for a such a small addition but agree that most changes are small individually but can add up to a significant mass.

[hober]

Hi @bokand!

I'm requesting a TAG review of document.prerendering.

We propose introducing a boolean property document.prerendering and associated change event to distinguish prerendering browsing contexts from regular ones for next-generation prerendering on the web, described more broadly at https://github.com/jeremyroman/alternate-loading-modes.
[…]
You should also know that...

This is a small piece of a large effort to bring back prerendering in a more predictable and standardized way. The entirety of the prerendering feature is a very large body of work so we thought it be good to separate out parts of it, where it makes sense, for ease of review. This feature would only ship as part of a larger launch of a new prerendering mode.

We really appreciate you breaking off a smaller piece of your work to make reviewing it more manageable. In this case, though, it's a smaller piece of your work that appears to stronly depend on other work of yours being in place too. For instance, the web platform doesn't currently have prerendering browsing contexts, so it seems premature to expose a DOM property that can be used to distinguish them from other types of browsing contexts. Maybe we should reschedule this review for after you've requested reviews on & we've reviewed the other things you're working on that this depends on.

[bokand]

Hi,

I was mainly looking for an early gut-check that this is a reasonable alternative to the previously removed visibilityState API (prerendering in some form has and continues to ship in some browsers).

Given there's no obvious objections (modulo @plinss' input) I'm happy to leave review of the details until the fuller feature review. I'm not sure what that means for this issue but feel free to put whatever deferring tags and/or close.

Thanks!

[atanassov]

Hi @bokand, after another look at the issue during our plenary session we are happy with the overall direction and you taking @plinss feedback on the overall API shape.

We look forward to seeing further progress and are happy to engage again as needed. Thank you for working with us.