Lea: generalisation of the prefetch/prerender attributes.. using json blob to define these rules in a sript element. Weird. There is precedent. Unclear .. syntax is confusing. source list / source document.. things to be said about syntax. Score is unclear how it's used. Question of do we want this logic to lie in a script element as json or should it be an html based syntax. Motivation - I am convinced, mentioned example of quicklink library that determins which links to prefetch automatically. Whole process is explicit, authors need to duplicate links to prefetch in the head. This allows the to handle this en masse to some degree. More extensible because its json, can add more properties. Main point is do we agree that this is a problem that needs to be solved, and is json in a script element a good way to solve it? Low level stuff we can talk about another time, or just leave a comment. I don't know any history about this.. seen speculation rules in our agenda a few times.. some background?

Dan: based on speculation rules? Leave comments and questions..

Lea: [will leave comment]

reading response

Hadley: using a lot of bandwidth in connections that are not able to handle it?

Amy: i think we did bring this up and privacy stuff for prerender.. but don't think most of the privacy concerns apply to prefetch.... assume it would take note of the user's context and not prefetch or prerender stuff on low bandwidth

Dan: left comment we will revisit at plenary

[update - bumped to 9th May]

Dan: Reviewing status ... no info on multistakeholder but some developer feedback has come in.

[punted to B hope to get some feedback from Rossen]

latest comment from requestor

Amy: lea left a review - not sure if the answers are satisfactory - I also did a related review.

Dan: let's maybe organise a special session on this? I can reach out to Chris H at Google.

Amy: it's interesting to know why they're not getting interest from other vendors... But doesn't feel like the sort of thing that if only rolled out in Chrome it would break web sites across other browsers.

Peter: marked pending feedback - we got some...

Rossen: says "we'll work on it, thanks for the ping"... i think it's safe to push it back ...

Peter: bumps

Amy: they reopened the review for prefetch - though it's pre-rendering.

Dan: Same comment left in the Mozilla standards positions and no response. Likewise discussion about prefetch.

Yves: adding a new http header is not an issue in itself. All the things people need to configure is becoming a bit much. Would be good to either reuse something existing by adding a new value. Even that adds to complexity. Or finding a way to .. define profiles that will select a set of behaviours or something like that. Still need to have a more comprehensive description of all the knobs used for security wrt all the http headers. We miss a comprehensive picture of all the http headers and their interactions, not only for this proposal, many recent proposals

<blockquote> We're noting a lack of multi-stakeholder interest in this. Do you have any info on this can you can share? We're concerned about developer complexity when it comes to this feature, especially considering the need for a new HTTP header that requires server configuration. Is there an alternative design that wouldn't require as much complexity? Never the less, regarding the design it's good to see it's an opt in. </blockquote>

leaves comment

Tess: looks like they filed a couple of issues based on Lea's feedback.. one of them is closed and the other hasn't had comments...

Dan: parsing Domenic's response - yes the complexity is the http header - requring server configuration... I'll make that clear.

<blockquote> Hi @domenic - Sorry for the mixed messages. Lea was asking specifically about the [new proposal](https://github.com/w3ctag/design-reviews/issues/721#issuecomment-1344814699) from @kjmcnee and I was referring to general updates of the original subject of the review. So yes, we would very much like to see a separate review opened when there is a new proposal. However the explainer link Kevin provided is to a document fragment, not to a [separate explainer doc](https://tag.w3.org/explainers/). Could you please clarify what we're being asked to review? To be clear: if it's a new piece of functionality that can be written up in an explainer doc, with the specific user needs being addressed, then please open up a new review (with a new explainer). If it's a delta to something we're already reviewing, then please update the current review text/explainer and let us know specifically what changed and why in a comment. </blockquote>

Amy: they've replied - the person who we thought was making a new proposal says they are making a delta.

Amy: we're supposed to reviewing the explainer that they keep updating.

Dan: the explainer

Amy: lea left some comments as well.

Dan: this is what we are talking about

Amy: still under active development; shipping in chrome; noone else is interested; explainer has no user needs in it (but may be too late to tell them that)

Lea: No archietctural concerns with the actual functionality. However I don't like the syntax. see comment

Dan: have they addressed those issues?

Lea: they opened up issues for some of them. I see one of them is resolved. Others [in tag] should look at syntax as well.

Dan: are there other examples where the same pattern is being used, around the use of JSON?

Peter: import maps

Dan: if there are other examples then maybe it's not..

Lea: import maps are using json to define metadata, but not to essentially annotate html elements. The only precedent for using a differetn language to annotate html is css (not saying they should have used css for this)

Dan: what about web annotation?

Amy: it's only a data model.

Rossen: proposal to use an <a> attribute? Do we have feedback on what can be better?

Peter: i don't understand json being used to annotate HTML elements? Isn't this one blob of json that's metadata for the document?

Lea: it's like a mini querying language about which elements it applies to.

Peter: selector matches... tagging elements. The rest is more of a map of the site.

Lea: My impression is that any anchor that meets those criteria would be (or not be) pre-rendered.

Peter: yes that example would better be on the element..

Lea: does this apply to link tag? image element?

Amy: it's about pre-rendering things the user might click on? So it would only work on href?

Lea: I think it's only about <a> elements.

Peter: I agree that the selector matching seems like a layering violation.

Lea: will create future features that use same syntax... precedent...

Peter: everything other than the selector matches seems like metadata about the site... that seems like it should be one blob of data somewhere. Could be a map on a site...

Rossen: no well formed opinion.

Amy: an interesting issue in their repo... Alex says "woould have expected this to come up in TAG review"...

Lea: the syntax doesn't allow for likelyhoods to be changed. My understanding is that the json is read once. Whereas if this was an attribute on the anchor then it would be dynamic.

Peter: how does that work if you have multiple pages...

Lea: something to define in the spec...

Amy: should we invite the requestor to come talk to us?

Peter: if this shipped in chrome and nobody else cares is this a waste of time?

Amy: the conversations are ongoing so it's at a stage where we could influence.

Lea: do they need the whole power of RegExps in href matches?

Peter: wasn't there another proposal for URL matches?

Lea: URL pattern.

Yves: yes in service worker and they ruled out RegExp because it's not cheap.

Lea: if they don't need it then they could just use selector matching... If their entire selection ctiteria can be described with selectors then why do they need this microsyntax at all?

Dan: does seem like it adds complexity - yet another query syntax..

Peter: does look like they're referring to url pattern spec, not a regex

Peter: should this be in CSS?

Rossen: elaborate

Peter: well selector matching.. it's a language for mapping properties to random HTML .. can be referenced by multiple pages ..

Lea: reactive

Peter: question is can you consider this presentational?

Rossen: that's my issue.

Peter: you could start to consider this presentational? doesn't preculde it from being in CSS.

Lea: i don't think that's a terrible idea though CSS doesn't have URL pattern matching. Maybe CSS could add URL pattern matching... that could be useful for CSS as well.

Points to raise:

• Have they considered using CSS?
• Concern continues about use of a novel JSON format for annotation
• Something about user needs not being clearly defined in the explainer
• Meta issue: Things that need to annotate HTML elements en masse that are not necesarilly presentational - how should they work?

Amy: explicit referer - if the user goes on to click the link - if the referer policy is different - it still uses the referer policy for pre-rendering.

Amy: if you set the referer policy in the json and in the link then the pre-renderer referer policy takes precedent. Are there consequences for this? Maybe means if there is a link to an external site that they author doesn't trust - but pre-rendering is configured differently - then it could have possible privacy implications? could be a stretch. [posted a question]

<blockquote>

Hi there,

We looked at this again in a breakout today.

The general consensus was that we agree that the functionality is useful, but we have some architectural concerns about the syntax this is introducing in the Web Platform, especially since its is introducing a novel precedent that could affect the direction of even more future Web Platform features.

One thing that came up in the discussion was that this is syntax that is annotating other HTML elements en masse, and the only precedent in the Web Platform for doing so is CSS. Since it could be argued that this is presentational, we were wondering if you have explored extending CSS for this.

Most of your criteria syntax is CSS selectors anyway, and while Selectors do not include matching for URL patterns, this would be more broadly useful anyway, and would make a good addition to selectors anyway. Since CSS is inherently reactive, this would also naturally afford dynamic scoring for links.

It seems that something like this could reduce the API surface of this feature to a couple of CSS properties, making it simpler to implement and test.

Sorry this has been taking so long. We're trying to make a concerted effort to come back with actionable feedback so we can close this issue as the consensus is generally positive. We look forward to hearing more as the origin trials progress. If you have other specific issues you would like to ask for TAG's feedback on please let us know.

</blockquote>

Rossen: we need to move this forward in a focussed way.

Dan: I assigned Lea. Let's put this on the agenda for next week and tackle it with Lea and Tess if possible Rossen (remote) to chat on a breakout at the f2f.

We left several comments on the review with things we spotted, including:

Hi,

@cynthia, @LeaVerou, and @hober took a look at this during our Tokyo F2F today.

We are sympathetic to the requirements this sets out to fulfill. The complexity of [document rules](https://github.com/WICG/nav-speculation/blob/main/triggers.md#document-rules) is concerning. While having solutions that can cover the whole spectrum of use-cases is nice, significant added complexity will have adverserial effects on adoption - and whenever possible we value [simpler solutions](https://w3ctag.github.io/design-principles/#simplicity) that an average developer could easily understand and make use of.

If you could propose a simpler approach that could cover say, [80% of the use cases](https://lists.w3.org/Archives/Public/public-html/2007Aug/0495.html) as an alternative - we would love to see this. One example that came up in our discussion was an attribute on `<a>` elements instead of an entirely separate technology. After all, more complex approaches can always be added later, if the need arises.

One bit about eagerness - it would be useful to state (maybe not normatively?) that ideally implementations should provide  a way for the users to set their prefetch preferences, and user preferences should be treated as higher priority than the page-declared eagerness preference - in particular in low-data/bandwidth scenarios.

Peter: looks like we got some feedback.

Dan: aside - we push back a lot about developer complexity. But we don't really have it documented as a design principle. Should we?

Lea: we do have something... consider tradeoffs? Prefer simple solutions

Hadley: and a reference in EWP, about keeping it possible for everyone to make a webpage, not needing a team of hundreds.

Lea: it's about the tradeoff, developer complexity needs to be justified by the benefit. In this case, when we looked at the big picture, they're adding this complex feature and a different syntax, and the benefit seems rather small - automating something you can do with js anyway

Dan: even Prefer Simple Solutions, it doesn't lay it out as the issue is when you add developer complexity you're giving developers a lot more work to do. The point about is it justified. Maybe there's just an addition to 2.1

Lea: something that clarifies, talks about tradeoffs.

Peter: agree it could be stronger, this keeps happening

Lea: what to reply here? I don't think it's justified... Ading an entire block of json with its own syntax with a filter scheme that combines url patterns and css selectors... I'm not sure it's worth it. Neither did Sangwhan or Tess when we looked at it

Dan: It would be one thing if this was the only way to do it and it had support from additional implementers. Given the lack of support for additional implementers... already an issue with multistakeholder

Amy: We could say "please go find more stakeholders and work together to make this less complex"

Peter: It's just in WICG right now...

Lea: I think the bar for adding a new type of json blob that gets added to html, the bar for that should be pretty high. Compared to adding an html attribute or a css property. We've done this for importmaps which is way more of an important feature than this. I could argue that this is also in the same category as linking to a manifest, sort of extension to the web platform. The benefit should be of that magnitude. If it's not, they should work with existing web platform technologies instead of adding new ones. Add html syntax or a css property.

Lea: also it limits resusability. You have to include inline json on every page, you can't link out to it.

Peter: do we have a principle about locality of data? The further apart you keep related information the more likely it is to get out of sync

Lea: that's really good, please file an issue

Peter: this has that issue as well. By centralising the prefetch rules you're taking it away from the things that trigger these rules. As you edit the document it's more likely to get out of sync.

<blockquote>

We understand the arguments for a separate syntax; we did not argue that this is not useful. However, we think that the increase in complexity that adding an entirely separate JSON-based syntax adds to the Web Platform should be comensurate with the benefit developers get from it. Similar cases in the past that warranted this kind of increase in complexity have been JS import maps, or PWA manifests. We don't feel the benefit developers get from this is in the same ballpark, to justify this increase in complexity. Furthermore, considering the lack of multi-stakeholder support, it seems like the resulting fragmentation could create additional developer complexity and confusion.

We would like to suggest that you work with additional stakeholders to see if you can both garner additional support and find a less complex design.

See also:

• 2.1 Prefer simple solutions (TAG Design Principles)

</blockquote>

Lea: leaves comment