- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Tue, 18 Jul 2023 18:14:30 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-view-transitions-2] Should ViewTransitions be triggered for browser initiated navigations`, and agreed to the following: * `RESOLVED: Leave these cases explicitly undefined in the spec` <details><summary>The full IRC log of that discussion</summary> <fantasai> vmpstr: same spirit, but about browser-initiated navigation<br> <fantasai> vmpstr: it is a navigation, but should that do a transition?<br> <fantasai> vmpstr: reason it's a question is that the page might not expect that route to be animatable<br> <fantasai> vmpstr: but at the same time, if it's supported, could do a transition<br> <fantasai> noamr: regardless of address bar, we do support for bak/forwad in history<br> <khush> q+<br> <fantasai> noamr: but that could also create unexpected routes<br> <fantasai> noamr: address bar is a special case of something general, but many things that we do want to support<br> <fantasai> noamr: e.g. jump in history<br> <astearns> ack khush<br> <fantasai> khush: my take on this is that it's hard to figure out all the cases where we can say this navigation was intentional from the author<br> <fantasai> khush: easier to say that it's all same-origin<br> <fantasai> khush: and give some knobs for controlling which navigations trigger<br> <fantasai> khush: right now you would need some scrijpt<br> <fantasai> khush: but there are proposals for making that declarative<br> <fantasai> vmpstr: at least as a user, when I type into the URL bar, I'm beginning a new experience<br> <fantasai> vmpstr: I don't expect there to be anything to persist my cognitive state<br> <fantasai> vmpstr: so in that case a transition doesn't help me<br> <fantasai> vmpstr: so good point about back/forward, can also jump multiple entries<br> <fantasai> vmpstr: I would argue again that you're breaking your experience<br> <fantasai> vmpstr: so non-transition animation is good<br> <bramus> seems reasonable<br> <fantasai> vmpstr: happy to be convinced otherwise, but don't think we should try to do transition in every ossible place<br> <fantasai> vmpstr: but rather for cases where devs expect<br> <fantasai> khush: you mean user<br> <fantasai> vmpstr: no I mean developer<br> <fantasai> khush: if the user copies URL form a link and pastes...<br> <fantasai> vmpstr: I would still argue it's still a new thing<br> <dbaron> (I think I agree with vmpstr.)<br> <fantasai> Nicole: When you go from one page to anotehr, and the other origin doesn't expect it either, isn't this also unexpected/<br> <fantasai> vmpstr: for cross-origin, second page did not set up that navigation transition<br> <fantasai> s/vmpstr/Nicole/<br> <astearns> (I think I also agree with vmpstr - no transitions for browser-initiated navigations)<br> <fantasai> vmpstr: Agree, that's why we didn't pursue cross-origin originally<br> <fantasai> vmpstr: it's harder problem to work out<br> <fantasai> nicole: I think it would not be good experience if they have to say exactly which pages they want, could have thousands<br> <fantasai> nicole: so should be easy to opt in or out of having transitions<br> <khush> q+<br> <fantasai> khush: Phrasing is interesting wrt user vs dev expectations<br> <fantasai> khush: if i have transition from A to B, and I past in the URL<br> <fantasai> khush: as a developer I would expect the transition<br> <fantasai> khush: I wouldn't know how the navigation is triggered<br> <fantasai> khush: as a user, type in the new URL, the transition keeps the visual context<br> <fantasai> khush: as a user I think the animation would line up with what I epxect to see<br> <fantasai> khush: but yes, I'm curious about what web developers think<br> <fantasai> khush: we're not sure if how navigation was triggered changes things<br> <astearns> ack fantasai<br> <astearns> ack khush<br> <vmpstr> fantasai: need more information from authors and users, next steps to collect more expectations?<br> <fantasai> astearns: Anyone else with an opinion?<br> <fantasai> astearns: it sounds like just in the room, between khush and vlad we've got 2 different opinions<br> <fantasai> vmpstr: "browser-initiated navigation" isn't specified, and there are lots of types<br> <fantasai> vmpstr: I'm not sure this needs to be interoperable because not exactly web-visible<br> <vmpstr> s/vmpstr/noamr/<br> <fantasai> s/vmpstr/noamr/<br> <fantasai> astearns: Seems like we should just keep this issue open and see if we get a better sense of author and user expectations<br> <fantasai> nicole: I'm curious what % of users modify the URL in the navigation bar<br> <fantasai> nicole: seems like a nerdy power-user thing to do<br> <fantasai> nicole: so maybe not something to resolve on<br> <astearns> I do it, so I assume it’s something very few other people do<br> <fantasai> hober: I think the simple answer is that enough of them do that it matters.<br> <fantasai> khush: Out of all the navigation, figure out how many same-origin cross-document navigations happen, if the number is low enough take the easier option<br> <fantasai> khush: jumping multiple steps in history is also power user<br> <hober> qq+ myles<br> <fantasai> myles: They are not rare. Typing into the URL bar is not power user option<br> <noamr> q+<br> <hober> q- myles<br> <fantasai> khush: for a same-origin cross-document navigation... it seems like cross-origin is more common for typing<br> <astearns> ack khush<br> <astearns> ack fantasai<br> <noamr> q-<br> <vmpstr> fantasai: don't define in the spec, and revisit later<br> <fantasai> fantasai: I suggest we leave these cases explicitly undefined in the spec<br> <fantasai> faceless: and revisit later if we end up with a definite opinion<br> <fantasai> astearns: so proposed resolution is to leave undefined<br> <fantasai> RESOLVED: Leave these cases explicitly undefined in the spec<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-1640717965 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 18 July 2023 18:14:32 UTC