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?

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?

@nhiroki any updates to the above questions?

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

The updates have been merged in https://github.com/WICG/nav-speculation/commit/d8ce9b5586bcb079a3942bce079d3d0ee0d1fd17.

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.

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.

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!