Re: [w3ctag/design-reviews] Design Review: Speculation Rules (Prefetch) (Issue #721)

Hi again, and thanks for the feedback.

I assume that you're referring to the "where" condition syntax specifically<sup>1</sup>. For further context on that, we did previously revise it to be more general (see [#160](https://github.com/WICG/nav-speculation/issues/160), [#177](https://github.com/WICG/nav-speculation/pull/177)) in response to https://github.com/w3ctag/design-reviews/issues/721#issuecomment-1101600240. I did look at options leaning more heavily on CSS (and have taken another look now), but I still don't think it is a great fit here.

Speculation rules provide page authors with the ability to determine, across the page, what sorts of links are suitable to preload and what sorts are not. When that's determined by URL it looks a little bit like Content Security Policy or service worker scopes; when it's determined by page structure, CSS selectors are a useful tool. I actually would tend to expect the former to be more common, and so I'd like for it to have good ergonomics. I'm concerned putting it inside CSS syntax might hurt ergonomics in the URL pattern case<sup>2</sup>. The existing case of explicit URLs (especially for navigation other than to existing links) is not solved by a pure CSS solution.

For those speculation rules that do target links, I definitely want to be reactive to changes in document structure in the same way that CSS is – which is why the current proposal does use the selector syntax to describe that structure and Chromium's implementation relies on the style engine for invalidation. More deeply integrating this concept (related to navigation speculation) into CSS implementations and specifications seems from our experience more likely to increase the coupling with, and thus burden to, CSS implementations and specifications.

Fundamentally, this control over preloading doesn't seem presentational to me. Even though it leverages the structure and semantics of the document using selectors, it doesn't affect the appearance (or aural output, etc) of the page. The precedent we most had in mind when creating this was import maps, which also have wide-ranging effects on a page, via a JSON specifier syntax embedded in a <script> element. The JavaScript querySelectorAll API is another example of leveraging the CSS selector syntax to structurally match the document without being presentational in nature.

<hr>

<sup>1</sup> The JSON syntax generally has been previously discussed, but [import maps](https://html.spec.whatwg.org/multipage/webappapis.html#import-maps) (which are similarly declarative about behavior on the page) are comparable.

<sup>2</sup> I tried to expand on the idea of adding a :link-href pseudo-class which would do URL pattern matching on the href (after accounting for the document's base URL) of elements which match :any-link.

Proposed syntax:
```json
{"and": [
  {"href_matches": "/*\\?*", "relative_to": "document"},
  {"not": {"href_matches": "/logout?*", "relative_to": "document"}},
  {"not": {"selector_matches": ".no-prefetch *"}}]}
```

CSS selector:
```css
:link-href("/*\\?*" relative-to document):not(:link-href("/logout?*" relative-to document), .no-prefetch *)
```

CSS selector (quoted):
```json
":link-href(\"/*\\\\?*\" relative-to document):not(:link-href(\"/logout?*\" relative-to document), .no-prefetch *)"
```

It would be possible, but a little more awkward yet, to permit the dictionary-style (rather than shorthand) URLPattern construction, since there isn't precedent for embedding a dictionary inside a pseudo-class (existing ones generally take very few parameters).

While I could conceive of this being useful in style (e.g., to automatically style cross-origin or insecure links differently), I haven't previously heard demand for this in the CSS ecosystem. I think including this in CSS might actually increase, rather than reduce, the work required to specify, implement and test.

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

Message ID: <w3ctag/design-reviews/issues/721/1460327898@github.com>