Speculation rules: target_hint field

[nhiroki]

こんにちは TAG-さん!

I'm requesting a TAG review of target_hint field for speculation rules prerendering.

This extends speculation rules syntax to allow developers to specify the target_hint field.

This field provides a hint to indicate a target navigable where a prerendered page will eventually be activated. For example, when _blank is specified as a hint, a prerendered page can be activated for a navigable opened by window.open(). The field has no effect on prefetching.

• Explainer¹ (minimally containing user needs and example code): https://github.com/WICG/nav-speculation/blob/main/triggers.md#window-name-targeting-hints
• Specification URL: https://wicg.github.io/nav-speculation/speculation-rules.html
• Tests: https://wpt.fyi/results/speculation-rules/prerender
• User research: n/a
• Security and Privacy self-review²: This should be covered by the previous self-reviews for speculation rules and same-site prerendering. This feature just controls where a prerendered page is activated (current tab vs. new tab), and doesn’t expose new information.
  • https://github.com/WICG/nav-speculation/blob/main/speculation-rules-security-privacy-questionnaire.md
  • https://github.com/WICG/nav-speculation/blob/main/prerendering-same-site-security-privacy-questionnaire.md
• GitHub repo (if you prefer feedback filed there): https://github.com/WICG/nav-speculation
• Primary contacts (and their relationship to the specification):
  • Hiroki Nakagawa (@nhiroki), Google, contributor
  • Domenic Denicola (@domenic), Google, editor
  • Jeremy Roman (@jeremyroman), Google, editor
• Organization(s)/project(s) driving the specification: Google Chrome
• Key pieces of existing multi-stakeholder review or discussion of this specification:Prerendering and non-current target windows WICG/nav-speculation#168
• External status/issue trackers for this specification (publicly visible, e.g. Chrome Status): https://chromestatus.com/feature/5162540351094784

Further details:

• I have reviewed the TAG's Web Platform Design Principles
• Relevant time constraints or deadlines: We hope to start an origin trial with partners as soon as possible, so the sooner, the better.
• The group where the work on this specification is currently being done: WICG
• The group where standardization of this work is intended to be done (if current group is a community group or other incubation venue): WHATWG
• Major unresolved issues with or opposition to this specification: n/a
• This work is being funded by: Google

You should also know that...

n/a

We'd prefer the TAG provide feedback as (please delete all but the desired option):

☂️ open a single issue in our GitHub repo for the entire review

[torgo]

We're just taking a look at this today and noting that the section of the explainer doc you've linked to doesn't have explicit user needs indicated. Can you add something that indicates the user need you're trying to service here? I think it's something like "enhance the efficiency of pre-rendering so if the user's device does that pre-rendering work it's more likely to be used and therefore the user is more likely to have a performant experience" - is that correct?

[matatk]

Also, the explainer mentions the desire to deprecate this, when the engineering work is done. I appreciate it's hard to predict how the work will go, but is there any way to firm up the timeline in the explainer, or for the public to track when it's complete?

[plinss]

@nhiroki any updates to the above questions?

[nhiroki]

Sorry for my late action. @robertlin-chromium is now updating the explainer.

[domenic]

The updates have been merged in WICG/nav-speculation@d8ce9b5.

[jyasskin]

For our background:

1. https://github.com/WICG/nav-speculation/pull/173/files#diff-086d7831ccea2721156a3a66a719f58f0eb0501d4b0da344f07e7a0df46a3efeR151, saying it would take a year or so of engineering effort to remove the need for this field, was merged about 2 years ago. Is there an updated estimate for how long this field will be around? I see that https://issues.chromium.org/361129302 exists to track progress on this effort, but it doesn't have that estimate.
2. Have you gotten any indications from Gecko or WebKit (even though they haven't supported prerendering itself) about whether they'd have the same implementation constraint that benefits from this field? Does this field affect Mozilla's argument against the JSON syntax? Without having deeply investigated it, this field might support their argument to put rel="nav-prerender" on <a> tags since those already have the target attribute.

FWIW, after skimming the description, it seems like this is designed well, so that it can fade away once it's no longer needed, and that it doesn't add much complexity.

[jeremyroman]

Without stepping on @nhiroki's toes, the document rule syntax does allow selecting links in the page, and when that is done, the target attribute is indeed implicitly used.

[jyasskin]

Thanks for explaining that this does re-use the <a target> attribute when that's available, and sorry for missing it in my review. We discussed this in our breakout session yesterday:

Please keep working with Mozilla to figure out the right consensus syntax for this. Beyond that, we don't see any architectural issues and (ignoring any worries about the underlying feature) are satisfied with this extension. Thanks for sending this review!