Re: [w3ctag/design-reviews] Incubation: speculation rules `form_submission` field for prerendering (Issue #1192)

robertlin-chromium left a comment (w3ctag/design-reviews#1192)

> Thanks for the clarification! [@xiaochengh](https://github.com/xiaochengh) and I have continued looking at this and had a few more suggestions and questions.
> 
Hello Dan, thanks for the reply.

> * The fact that this is meant to be injected dynamically leads us to wonder whether speculation rules should have some kind of JavaScript object model. The dynamic way this will need to be used is pretty unergonomic, where a `<script>` element is created and set to JSON text (potentially from serialized JSON object) and then injected into the DOM. The inconsistency with how normal speculation rules are used may also be a source of confusion for developers. An API to make this more author-friendly is worth considering as future work.
> 
Possibly. But this seems orthogonal to this change. Most usage of speculation rules is via the HTML or Speculation Tags where the JSON-based syntax is more ergonomic and readable for developers. So the Speculation Rules API was designed primarily with that in mind.
This is an additional, but less common, use case that has been requested. However, DOM manipulation has always been an option to use the API via JavaScript and [has been in our documents](https://developer.chrome.com/docs/web-platform/prerender-pages#add_speculation_rules_dynamically_through_javascript) since the beginning. It is used by many developers without confusion.
Does this additional JavaScript-only tip the balance to introduce a JavaScript API for speculation rules? We don’t think so. That seems a high bar and would need lots of consideration as to how this would work with the script tag solution that drives the API now.
The JSON syntax was debated a lot before the API was launched (including [in the TAG review](https://github.com/w3ctag/design-reviews/issues/721)), but since launch we’ve had pushback from developers, and feedback seems to be that they link the syntax.

> * We didn't understand the mention of `form-action` CSP as a justification for why the feature is needed. We take the point that if a form submission navigation is going to be blocked by CSP, the `form_submission` speculation rule could prevent wasting the resources to prerender the page that isn't going to be navigated to. But isn't the form basically broken at that point regardless? A wasted prerender seems like it's of relatively low importance if the site isn't working.
>   
Currently the speculation can be started and is ignored as you say. That’s what happens now. This change is specifically to address that wastage and allow forms to benefit from speculations rules.
The reason this doesn’t work now, is that browsers (or Chrome at least) effectively send form navigations in a different “mode” for reasons like different CSP checks. So the new field allows the developer to signal this is a form navigation to speculate. In many ways it resembles the [as attribute for link rel preload](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/link#as) in that it hints the type of navigation (rather than type of resource) the speculation is for.

>   * We also had a hard time following the part of your [earlier reply](https://github.com/w3ctag/design-reviews/issues/1192#issuecomment-3996180497) around "Without this field, prerendering will always be prepared as non form submission and will actually break the current spec." Can you clarify further? What aspect of [populating a session history entry](https://html.spec.whatwg.org/multipage/browsing-the-web.html#populating-a-session-history-entry) will be broken here, other than the fact that we might end up with a wasted prerender since the CSP will cause it to fail to load?
>  
Sorry for the confusion. After checking with the team, https://wicg.github.io/nav-speculation/prerendering.html#navigate-activation will find a candidate to activate when navigation starts but https://html.spec.whatwg.org/multipage/browsing-the-web.html#populating-a-session-history-entry step 5.4 will stop the navigation from starting in pre-navigation. So the main problems are still preloading resource waste and the implementation limits (at least for Chrome).

> * [`target_hint`](https://github.com/w3ctag/design-reviews/issues/931) is referred to as precedent for this, but for that feature the [explainer](https://github.com/WICG/nav-speculation/blob/main/triggers.md#window-name-targeting-hints) mentioned that `target_hint` could someday maybe be deprecated/removed if Chromium does some internal work such that it's no longer needed. There's a bug tracking that: https://issues.chromium.org/issues/361129302. Should the removal of the `form_submission` rule be tracked in the same way, in case Chrome ever does the engineering work so it's no longer needed?
>
It could be, the current implementation of Chrome depends on the state of `cspNavigationType` in many places, so the prerender field is needed to handle navigation correctly at the moment. We suspect that other browsers may be similar as some of the source code has a similar field.

> * The triggering mechanisms mentioned in the explainer (hovering over a submit button) don't seem like they'd work well with mobile. Please consider adding a note on this and consider whether it should be used together with other mobile-friendly triggering mechanisms.
>
Yes, we have updated this example. (https://github.com/WICG/nav-speculation/pull/433) That was one use case we did hear about from developers, but agree it’s not very inclusive of mobiles.

Ultimately, for forms, we think the heuristics to use are best left to the developers as noted in the explainer (“When the form is sufficiently complete to speculate is best left to the developer to decide rather than for browser heuristics”)




-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1192#issuecomment-4484531611
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1192/4484531611@github.com>