Re: [csswg-drafts] [css-view-transitions-2] Define navigation descriptor for @view-transition (#8783)

The CSS Working Group just discussed `[css-view-transitions-2] Define navigation descriptor for @view-transition`, and agreed to the following:

* `RESOLVED: auto means push or replace that's not browser ui, or traverse with any user involvement, excluding any reloads`

<details><summary>The full IRC log of that discussion</summary>
&lt;flackr> noamr: we resolved on having a view transition rule with a navigation descriptor having values of auto and none for cross document VTs<br>
&lt;flackr> noamr: we said in the future we'd resolve on what auto means and whether it's the right name<br>
&lt;flackr> noamr: let's figure this out<br>
&lt;flackr> noamr: we think any navigation except reload should be considered auto and automatically trigger a VT<br>
&lt;flackr> noamr: we want to be a bit more aligned with the navigation API. Navigations that are not cancelable should not trigger an auto VT<br>
&lt;flackr> noamr: this mainly includes browser UI navigations, e.g. typing a URL in URL bar<br>
&lt;flackr> noamr: the idea is to align more with this, and say auto means any navigation that is not browser initiated and any navigation that is a traverse navigation (e.g. back/forward)<br>
&lt;flackr> noamr: an outlier to both is reloads, we resolved before they shouldn't be automatically a VT, but reloading via JS can be canceled with the navigation API<br>
&lt;flackr> noamr: the proposal is to call this auto, to include any traverse navigation, any push/replace navigation that is not browser UI initiated, and to discuss whether programmatic reloads should be included, probably not<br>
&lt;Rossen_> ack fantasai<br>
&lt;noamr> q+<br>
&lt;flackr> fantasai: I think saying you can cancel it via JS is not the right way to do this. We want this to work for people not writing JS. By default we can allow for reloads (programmatic or user initiated), but it should be an option<br>
&lt;khush> q+<br>
&lt;flackr> fantasai: we don't know if the author wants to have something reload more invisibly rather than trigger a transition<br>
&lt;flackr> fantasai: e.g. navigating from one catalog to another might look like a page swipe but reload shouldn't. auto shouldn't include these cases and the author should request it explicitly<br>
&lt;Rossen_> ack noamr<br>
&lt;fantasai> s/catalog/catalog page/<br>
&lt;flackr> noamr: programmatic reloads are JS to begin with. We don't know what people use them for. You probably wanted a reload pattern in your application or because you reach a certain state want to force a reload<br>
&lt;flackr> noamr: the idea of hanging off of what can be cancelled via JS kind of made sense for navigations initiated from JS<br>
&lt;flackr> fantasai: the person writing the JS might not be the same person writing the CSS<br>
&lt;flackr> fantasai: the person designing the transitions needs to be able to design this independently<br>
&lt;flackr> noamr: do people have views about excluding browser UI initiated navigations?<br>
&lt;flackr> fantasai: this seems vague, there's a lot. Does this include back/forward?<br>
&lt;flackr> noamr: no, anything except traverse<br>
&lt;flackr> noamr: e.g. bookmarks, typing in url bar, extensions etc<br>
&lt;flackr> fantasai: what is traverse? for clarity<br>
&lt;flackr> noamr: traverse is going back/forward in history or clicking something through the history list<br>
&lt;flackr> Rossen_: what about meta tag refresh?<br>
&lt;flackr> noamr: that would be a reload, or a replace if it goes to a different url<br>
&lt;flackr> noamr: so that's equivalent to a programmatic replace so it wouldn't be considered browser ui<br>
&lt;flackr> noamr: it would have a VT<br>
&lt;flackr> Rossen_: so on every refresh in fantasai's example you'd be flipping pages<br>
&lt;flackr> noamr: yes, because it's like a regular replace navigation<br>
&lt;flackr> fantasai: so to summarize, you want to introduce a keyword that says every navigation initiated by the user or the page except a reload of the page, or a browser UI navigation that is not a ....<br>
&lt;fantasai> s/a ..../history traversal/<br>
&lt;Rossen_> q?<br>
&lt;flackr> noamr: the keyword means any navigation that is not browser ui plus any browser ui traverse (i.e. including links, back/forward, forms, meta redirect)<br>
&lt;flackr> khush: this keyword called user involvement, is an existing thing in the spec we're leaning on. script, activation behavior and browser ui<br>
&lt;flackr> khush: script is like using history api or navigation api<br>
&lt;flackr> khush: activation behavior is where &lt;a> activation triggers navigation<br>
&lt;flackr> khush: browser ui is interaction with browser UX to trigger navigation<br>
&lt;flackr> khush: the desire here to align with the nav API is that it's a bit weird to trigger a VT from a navigation you can't observe via script<br>
&lt;flackr> khush: in that we haven't exposed it to script normally<br>
&lt;flackr> khush: also you can't customize it via JS, so there will be problems with not being able to customize it<br>
&lt;flackr> khush: so i have concerns with only being able to customize it via css<br>
&lt;flackr> khush: html has 4 keywords, push, replace, ?? and traverse<br>
&lt;flackr> s/??/reload<br>
&lt;flackr> khush: if navigation type is push or replace, and user involvement is not browser UI<br>
&lt;Rossen_> q?<br>
&lt;Rossen_> ack khush<br>
&lt;flackr> khush: one class of navigations is your type is push/replace and involvement is not brower UI, i.e. script or activation behavior, this is included<br>
&lt;flackr> khush: for traverse, the html spec has a special carveout because authors often want to include these. For this it should be allowed even if browser ui was involved<br>
&lt;flackr> khush: the fact that you can observe it helps customize<br>
&lt;flackr> Rossen_: does this satisfy concerns / questions?<br>
&lt;flackr> fantasai: yes, and last category is reload.<br>
&lt;flackr> fantasai: ???<br>
&lt;fantasai> s/???/I think we should exclude reload in all modes/<br>
&lt;khush> In summary, auto would match:  Any traverse navigation. Any push or replace navigation whose user involvement is not browser UI.<br>
&lt;flackr> noamr: resolution would be auto means push or replace that's not browser ui, or traverse with any user involvement excluding any reloads<br>
&lt;fantasai> s/excluding/, excluding/<br>
&lt;flackr> RESOLVED: auto means push or replace that's not browser ui, or traverse with any user involvement, excluding any reloads<br>
&lt;Rossen_> Zakim, end meeting<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8783#issuecomment-1885359766 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 10 January 2024 18:03:41 UTC