Peter: looks like performance

Lea: one basic thing I'm unclear on is soft navigation something that happens anyway and this is allowing developers to observe it and react to it? Or is this something that developers opt in explicitly?

Peter: something developers do, like by using the history api to go to a url without fetch

Lea: I thought it was about soft nav that already happens, but unclear if clicking on a hash is soft navigation, or only things initiated from history or navigation api?

Peter: good question. also, triggered by user gesture and modifies dom. Does that exclude fragment navigations? Not sure every soft nav will change the dom... but probably true.

Lea: what is the purpose of the criteria that it needs to change the dom? If it is to detect navigations in an spa that change the page vs navigations that scroll you to a different section, what about cases where developers use hashes to display a different part of the page and hide other parts, or implement tabs. All sorts of these things sound lke they should be soft navs but it wouldn't modify the dom if it's all done through css. And what about cases where you have a component which changes its content and changes happen in shadow dom.. does that count as a dom change? seems hairy. How long after do you listen for a dom change? what if the navigation happens now and the dom change happens seconds later because there was an animation first?

Peter: seems like a weird requirement. The purpose for changing the url is to reflect state, that you want the user to be able to share. Maybe they should describe it that way somehow. But they're talking about a heuristic that the browser can use to detect that this happened. Then I'm wondering why it's the fact that you called the api to change the url? Unless they do want to distinguish just changing the fragment. But why exclude that? Could be state.

Dan: motivation section is well written, I understand where they're coming from. From a performance standpoint.

Peter: in general .. seems like a hole that these soft navs aren't triggering performance apis

Dan: is soft navigation a term of art? I couldn't understand if they're defining this term, or are they saying this is what soft navigations are and this is what the soft navigation api is... are they making an assumption that we already know?

Peter: my take is that they're defining the concept of soft navigation, but I don't know if this is a common term

Dan: related to Lea's point - it seems very narrow, this definition. There could be other ... it sounds to me like a UI/UX thing. Rather than a api.. sounds like a pattern .. they're defining an api and a pattern? Is there a term of art already used for same-document navigation?

Peter: same-document navigation

Peter: not just that there's a dom manipuplation, but a 'meaningful' one. "reasonably considered navigations" - sounds scary. How will they make that work? They have an open question about gmail's compose button, and argue that would be considered a soft nav, or could argue it's an interaction. Trying to determine some definition of interaction vs navigation.. not sure if that's a distinction with merit, that a heuristic can reasonably determine, except for on a handful of known sites like gmail. Does that make sense?

Lea: yes

Dan: Yoav got back to us....

Peter: he updated the explainer to answer some of our questions...

Lea: are the heuristics normative?

Peter: looks like they are still figuring them out....

Lea: we should review independent of the heuristics... ?

Peter: curious about multi-stakeholder.

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).

Peter: no response to Lea's last comment, 2 weeks ago

Lea: we can wait

Lea: added pending external feedback, that's the status

Peter: anyone else to ping? I can ping Yoav

bumped

we read yoav's response

Lea: our issue was the heuristics didn't seem very good and the response was that they're normative and cannot be tweaked... There are webkit and mozilla positions - just filed.

Lea: meta In the explainer template - we should ask for links and whether the response was positive / negative / mixed / no response yet.

on "contentful paint"

Peter: something that causes rendering ....

Lea: spec points to the def of a contentful element... but they're -- not sure how ...

https://www.w3.org/TR/paint-timing/#first-contentful-paint

Peter: something that can render gets rendered due to user interaction... e.g. change a css state and it causes a render...

Lea: I have afeeling this is the right direction... spec describes "first contentful paint" but doesn't define "contentful paint"

Peter: I think it does .. it's if it's paintable and contenful.

Lea: it talks about a document... the document may contain many elements that are paintable and contentful - so what makes a paint contenful.

Yves: when there is a paint occuring then the element is subject to a contentful paint...

Peter: I think this is excluding things like background...

Lea: what if an element is contentful and CSS changes its background...

Peter: don't know how they define a contentful background image...

Lea: It would be good to have answers.

Peter: It's a render that flips some pixels.

Peter: question - a contentful paint that's a direct result of user interaction. How can they tell? What if the aninmation made the change... Comes back to original question about heuristics.

Lea: As a general UI principle you should allow opt out when introducing heuristics. We have precedent of heuristics that could not be overridden and it was pretty bad: e.g. CSS specificity, people ended up entirely not using selectors for querying to avoid specificity.

Lea: adding history elements based on a soft navigation would be a bad user experience... So if it's just for measuring performance then...

Peter: not being exposed anywhere other than performance observers... agree you don't want to based user interaction or behaviour on this.

agree to post

Peter: holes in their heuristics. Lea's primary point which I agree with is just relying on heuristics seems fragile. Not being able to override is problematic

Dan: looks like Yoav was agreeing with you .. future iteration..

Peter: makes the point they've experimented for a year and haven't seen a lot of instances of these other ways of navigating being doing. Question what he's looking at. Not seeing CSS only navigations is not surprising because that's a new feature, but it's going to become more popular over time. The bigger issue is not having any author control over the heuristics, or augment or override the heuristics. Not harmful. But just a performance thing... bigger issue if it ever gets folded into something else, a higher level detection of navigation, other concepts of navigation. Would still like Lea's feedback.

Dan: does it make sense to set this to proposed closed and get Lea's feedback async?

Peter: currently satisfied with concerns, not sure if Lea is willing to do that.

Dan: bump it

Yves: not in the abyss... Latest comments 2 weeks ago...

Looks like we can close it. Concept should not be used for anything user-facing, and we don't want this to be used more broadly.

Marked "propose closing"