A (rough and initial) spec for this is at https://wicg.github.io/soft-navigations It's not yet ready for a full review, but could help understand how this integrates with the rest of the platform.

Hi @yoavweiss -- thanks for bringing this to our attention. Our biggest question has to do with the question of DOM modifications. You state a soft navigation "modifies the DOM" but it's not clear why this is a requirement? It seems like you're trying to make a distinction between "navigations" and "interactions", it's unclear how this subtle (and underspecified?) distinction can be reliably determined by your proposed heuristics. We can imagine that the heuristics can be defined to catch current examples but would be wrong about future applications. We wonder if simply using the navigation API should be the trigger, and then possibly provide the developer a hook to filter out navigations they don't feel are worth tracking would be more reliable?

Thanks for taking a look.

I added a goals section to the explainer that clarifies some of the constrains around the design.

You state a soft navigation "modifies the DOM" but it's not clear why this is a requirement?

That's a great question. I've ran a bunch of experiments, and this seemed to align well with SPAs today. But it is possible that the heuristic will evolve as part of the Origin Trial, or given this reported issue.

We wonder if simply using the navigation API should be the trigger

The Navigation API doesn't provide any more guarantees than the History API did regarding what is and isn't an actual navigation.

possibly provide the developer a hook to filter out navigations they don't feel are worth tracking would be more reliable

The newly added [goals] section should clarify why that strategy will not work well for the use case.

Hi @yoavweiss,

We looked at this again today during a breakout and had some questions. If the heuristics are still being worked on, is the purpose of this review to review the rest of the API, assuming the heuristics are good? Are the heuristics meant to be normative? Will there be ways for the developers to tweak this in either direction (both opt out of a detected soft navigation as well as be able to declare something as a soft navigation that was not caught by the heuristics). We also wondered about multi-stakeholder interest. https://chromestatus.com/feature/5144837209194496 lists "No signal" for both Firefox and Safari. Have standards positions been requested? If so, including the links to these would be useful (we plan to make this part of our explainer template very soon).

Thank you!

@yoavweiss any feedback?

Apologies for my delay here, I was implementing some changes related to this feedback to test their feasibility.

If the heuristics are still being worked on, is the purpose of this review to review the rest of the API, assuming the heuristics are good?

The heuristics are in fairly good shape, so I wouldn't expect significant changes on it in terms of implementation. I'm hoping to get the spec to catch up with the implementation in the next few days.

Are the heuristics meant to be normative?

Yeah, that's the intent.

Will there be ways for the developers to tweak this in either direction (both opt out of a detected soft navigation as well as be able to declare something as a soft navigation that was not caught by the heuristics).

Not at the moment. This might be future evolution of the feature, but there aren't current plans for this.

We also wondered about multi-stakeholder interest. https://chromestatus.com/feature/5144837209194496 lists "No signal" for both Firefox and Safari. Have standards positions been requested? If so, including the links to these would be useful (we plan to make this part of our explainer template very soon).

Mozilla position WebKit position

Our biggest question has to do with the question of DOM modifications. You state a soft navigation "modifies the DOM" but it's not clear why this is a requirement?

Thanks for that feedback. The current implementation changes that requirement from "DOM modification" to a contentful paint that's a direct result of user interaction. I'll modify the spec to that effect.

Hi @yoavweiss,

Thank you for clarifying. We took another look today. Switching from DOM manipulation to paint-based heuristics generally seems like the right direction, but we had trouble understanding the specifics from the Paint Timing spec. It seems to provide a definition for what a contentful, paintable element is, what the first contentful paint is, and which CSS images are contentful, but we're not quite sure how a contentful paint is defined and how this heuristic avoids false positives (e.g. hover effects that change a CSS background being counted as soft navigations).

Also, as a general principle, when introducing heuristics, it's generally good to also introduce a way to override the heuristic. If that's too hard, then the data collected by the heuristic should be treated as potentially noisy, i.e. this concept of Soft navigations should not be relied upon for anything that affects the user experience. For analytics, it may be ok; probably better to err on the side of false positives than false negatives, and include enough data that the false positives could be filtered out on the analytics side.

It seems to provide a definition for what a contentful, paintable element is, what the first contentful paint is, and which CSS images are contentful, but we're not quite sure how a contentful paint is defined and how this heuristic avoids false positives (e.g. hover effects that change a CSS background being counted as soft navigations).

In terms of spec, any paint that's considered for LCP is one that soft navigations consider as a contentful paint. This area (PaintTiming+LCP) is currently in the process of being rewritten to make it clearer.

^^ @clelland

In terms of hover effects, they may be considered as a contentful paint, but won't be counted as a soft navigation since:

• "hover" is not considered a user interaction (only "click" and keyboard events would). Reexamining the relevant algorithm, it seems like it's buggy. I'll fix it and add clarifications to the explainer.
• Only paints on elements that were appended into the DOM as a result of the interaction event will be counted as relevant contentful paints for soft navigation purposes.

Also, as a general principle, when introducing heuristics, it's generally good to also introduce a way to override the heuristic.

This seems like a useful principle! There's already https://github.com/WICG/soft-navigations/issues/13 requesting this. I agree that it can be useful, but given the analytics-only nature of the feature, I also agree that it's non-blocking.

Awesome, thanks! When do you think you may be able to make the explainer changes? I currently added it to be looked at again 2 weeks from now (next week is Design Principles week) but if you can get them in before our plenary this week (2am EST on Thursday) we may be able to close then.

I just updated the explainer to emphasize which events count for interactions. Let me know if that works! :)

Thanks! Could pressing a key also be the tab key? If so, how do you distinguish focus styling from soft navigations?

Edit: I guess this prevents that?

• In case of a “click” or a keyboard event, the handler triggered tasks that included history.pushState() or history.replaceState() calls, or a change to the document’s location.

But then where does the contentful paint come in?

One missing condition in my previous clarification (now fixed! thanks!!) is that the keypress is unfocused (i.e. its target is the body element). So a tab key that changes focus would not be considered for a soft navigation, but e.g. a tab key that is used to move between different pages would be.

• In case of a “click” or a keyboard event, the handler triggered tasks that included history.pushState() or history.replaceState() calls, or a change to the document’s location.

But then where does the contentful paint come in?

For a soft navigation to be detected, an eligible event ("click" or unfocused keyboard event) would need to spawn tasks that both change the URL and append DOM nodes that end up with contentful paints.

It still seems problematic that it requires a DOM node to be appended. I've seen (and implemented) soft navigations were the only DOM change was an attribute value (to select an active tab, for example, causing various display properties to take effect), it's not clear that would be considered 'appending a node'. I can see CustomState or even changing the value of a custom CSS property doing the same with no modifications to the DOM.

@plinss - Indeed CSS-only soft navigations are not handled by the current heuristic. So far after a ~year of experimentation, I've seen a single case in the wild where this is an issue. It seems like something we could solve in a future iteration of the heuristic, but one that would require a bit more research.

What about attribute value changes, are those considered 'appending a DOM node'? (If so, you might want to spell that out a bit better.)

Attribute change is not currently considered. I agree that for some attributes (e.g. an image's src attribute) it would make sense to include them eventually. I think that also can be part of a future iteration.

We understand that the current heuristics are based on most common current practices and it looks like you're prepared to evolve them as newer techniques become more popular. We're still concerned about lack of author control for extending/enhancing the heuristics, but given that this is only for performance measurements, we're going to close this as satisfied.

Our main remaining concern is that others may want to repurpose this signal in the future, and without author controls, this signal won't be reliable enough. Please consider adding a note to the spec to explain this limitation.

Thanks for flying TAG.