Re: [w3ctag/design-reviews] App history API (#605)

> @domenic we're just discussing again in our breakout today and one question that came up : is there any indication on multi-engine support at this point?

We're fairly early in the process and haven't reached out to other engines that much. That said, @annevk and @smaug---- from Mozilla have been engaged and helpful. Getting some more formal expressions of interest is on my radar to do in the near future, as things are starting to settle. (E.g. the spec text is beefing up in a way that makes it easier for implementers to evaluate how this meshes with their existing infrastructure.)

> @domenic we also discussed the 4 issues you pointed us to and considered the feedback already on those issues.

Thanks very much!

> For WICG/app-history#66 we think the URL bar should update immediately from a web user experience PoV - can you be more specific about the use cases where you think this would be detrimental?

My instinct aligns with yours here. However, I suspect there are sites today that consciously choose use the following pattern:

```js
someButton.onclick = async () => {
  const data = await fetchLotsOfData();
  await updateTheDOMMaybeWithSomeCoolAnimations(data);
  history.pushState(null, "", newURL);
};
```

i.e. they delay updating the URL bar until after the data has fetched and the DOM has updated. So in that issue I'm trying to tease out if there are framework or site authors who are indeed doing that consciously, and get a sense of whether they'd be OK switching to an immediate-update model, or if that would be a blocker for them using app history.

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