- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 09 Aug 2023 16:27:59 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Declarative Cross-document View Transitions`.
<details><summary>The full IRC log of that discussion</summary>
<fantasai> Topic: Declarative Cross-document View Transitions<br>
<fantasai> github: https://github.com/w3c/csswg-drafts/issues/8048<br>
<fantasai> khush: Last time discussed lots of good feedback.<br>
<fantasai> khush: main issue is figuring out declarative feedback for doing cross-document navigation transitoins<br>
<fantasai> khush: Sub-cases are same-origin vs same-site navigation<br>
<fantasai> khush: Same-document it's just syntactic sugar, can do via JS API in L1<br>
<fantasai> khush: but nice to have<br>
<fantasai> khush: First, if we go for simplest opt-in, binary yes/no allow/disallow<br>
<fantasai> khush: but a bunch of cases have different parameters, and authors may want to decide opt-in based on what navigation corresponds<br>
<fantasai> khush: additionally there are some parameters to decide what transition looks like<br>
<fantasai> khush: i.e. what elements animate independently, or how to style the animation<br>
<fantasai> khush: same-document / cross-document / same-origin / same-site<br>
<fantasai> khush: You call document.startViewTransition, generally that should be op-tin<br>
<fantasai> khush: but we found some cases where someone might wnat to disable transitions for prefers-reduced-motion<br>
<fantasai> khush: and declarative syntax makes this easy<br>
<fantasai> khush: For navigation, might want different animation depending on type of navigation<br>
<fantasai> khush: e.g. forward vs back<br>
<fantasai> khush: [missed]<br>
<fantasai> khush: Lastly, which page are you going to.<br>
<fantasai> khush: e.g. clicked item in the list, decides UI of next page, want to customize based on that<br>
<fantasai> khush: From all these cases, if there are some which are mutually exclusive, only thing that needs to impact opt-in<br>
<vmpstr> s/[missed]/there's also replace navigation, and push navigation/<br>
<fantasai> khush: wouldn't change opt-in depending on same-document vs cross-document, don't need to change if the DOM looks the same<br>
<fantasai> khush: In that case, have it be opt-in<br>
<Rossen_> q?<br>
<fantasai> khush: but if based on that you want to customize transition, e.g. back vs forward, change direction that content slides<br>
<noamr> q+<br>
<fantasai> khush: let's make that something that can be used to customize all CSS, not just this opt in<br>
<fantasai> khush: I thought at first to use an @media query<br>
<fantasai> khush: noam proposed using pseudo-classes instead<br>
<fantasai> khush: and there's precedent for doing this with @page at-rule<br>
<fantasai> khush: Right now 3 proposal<br>
<fantasai> khush: 1. Use @media queries for deciding navigation back/forth/specific URL<br>
<emilio> q+<br>
<SebastianZ> q+<br>
<fantasai> khush: also whether initiated via script, etc. All these cases are expressed as tokens in the opt-in rules<br>
<fantasai> khush: @view-transition takes a parameter, 'transition-trigger', and you can specify various tokens for allowing<br>
<fantasai> khush: Previously we discussed having reloads disabled by default, but with this syntax it's hard<br>
<fantasai> khush: It seems to imply reload<br>
<Rossen_> q?<br>
<fantasai> khush: Second tries to solve that by saying that we can add another parameter to the at-rule, which is just 'reload', allow/disallow; initial value can be disallow<br>
<fantasai> khush: only reason to do this is that media queries, they don't add any specificity, so can't add a UA style rule that says "don't trigger for reload"<br>
<fantasai> khush: Later on, one suggestion from SebastianZ to include reload token within the 'transition-trigger' list itself<br>
<TabAtkins> Wait, can't you tho? We don't need specificity, just order of appearance, right?<br>
<fantasai> khush: technically not mutually exclusive, because same-origin or cross-document is [missed]<br>
<TabAtkins> Ah tho if the author turned on some navigations that would override the "not on reload" rule then<br>
<vmpstr> any author opt-in would override the reload "opt-out"<br>
<vmpstr> yeah exactly<br>
<fantasai> khush: but we're not aware of use cases where people would want to do differently for cross-document vs same-document reload<br>
<fantasai> khush: Last option was using pseudo-class, use @view-transition but you can add a pseudo-class which is a mapping to the navigation type<br>
<fantasai> khush: then we can add a UA style rule @view-transition :reload { [no transition] }<br>
<Rossen_> q?<br>
<fantasai> khush: It will have more specificity, so UA rule would win<br>
<fantasai> khush: Because of that I'm liking this option the most<br>
<Rossen_> ack noamr<br>
<fantasai> noamr: Want to add that this conversation came from F2F where we were asked to think ahead to features we wanted in View Transitions<br>
<fantasai> noamr: even though all we want to do in L2 is the simple opt-in<br>
<TabAtkins> hmmm, i might suggest making the property comma-separated, one keyword per - then you can add additional features (like reload) to each iteration.<br>
<fantasai> noamr: idea that we think ahead to how things look like<br>
<fantasai> noamr: In all those options, the first version is very similar<br>
<fantasai> noamr: where we have a view transition rule and inside of it a navigation trigger etc.<br>
<TabAtkins> trans-trigger: none | [ [reload | no-reload] || <transition-type> ]#<br>
<Rossen_> ack emilio<br>
<fantasai> emilio: I wanted to mention that media queries seem like an odd choice here<br>
<fantasai> emilio: feels cleaner to just extend the rule to allow selecting the cases you want<br>
<fantasai> emilio: Media queries you can do anything inside them, not just view transition rules<br>
<fantasai> emilio: so unclear when that applies<br>
<fantasai> emilio: do we need to do a full style update?<br>
<TabAtkins> Bringing in specificity for the rule itself seems a little more complex than we need, and it seems strange to promote reload, specifically, to be the thing promoted to "selector"-ish.<br>
<fantasai> emilio: so it feels like an odd choice, so if we ned to add this kind of selector capability, extending the rule itself seems better<br>
<TabAtkins> q+<br>
<fantasai> emilio: Other thing to mention, we have a kind of precedence for this kind of stuff with scroll-behavior<br>
<fantasai> emilio: it was mentioned that what you want to do is e.g. disable imperative animations<br>
<fantasai> emilio: stylesheet would override<br>
<fantasai> emilio: that's not how scrollIntoView etc works<br>
<fantasai> emilio: so might want to be consistent with that<br>
<Rossen_> ack SebastianZ<br>
<fantasai> SebastianZ: Noam pointed out important thing, this is divided into 3 pieces<br>
<fantasai> SebastianZ: URL, type, and mechanism<br>
<fantasai> SebastianZ: was thinking about, maybe they shouldn't be part of the prelude but rather different descriptors<br>
<noamr> q+<br>
<fantasai> SebastianZ: so have a descriptor for each of these pieces<br>
<khush> q+<br>
<fantasai> SebastianZ: so you'd have a type descriptor that takes "reload | travers | etc"<br>
<fantasai> SebastianZ: a descriptor for same-origin / cross-origin<br>
<fantasai> SebastianZ: and a descriptor for the mechanism itself<br>
<Rossen_> ack fantasai<br>
<Zakim> fantasai, you wanted to clarify that origin wins over specificity<br>
<fantasai> scribe+ emilio<br>
<emilio> fantasai: Wanted to point out that in the cascade, origin is more powerful than specificity<br>
<emilio> ... so even if specificity of the :reload pseudo-class is higher UA origin would override<br>
<emilio> ... I also want to agree with emilio wrt stashing this on a media query<br>
<TabAtkins> q-<br>
<TabAtkins> actually i'm gonna just take my convo to the issue<br>
<emilio> ... SebastianZ's idea of encapsulating all these in descriptors makes sense, it's like @font-face<br>
<emilio> ... the other thing authors might want to control is defining the type of navigation based on the URL<br>
<emilio> ... and you might want to have that centralized<br>
<Rossen_> q?<br>
<emilio> ... that way when you need to update any of these types of navigations you don't need to go through everything<br>
<fantasai> s/everything/everything to update the URL list everywhere/<br>
<fantasai> ... I think it would be useful to style based on the class of view transition (author-defined class)<br>
<fantasai> noamr: Idea of having descriptor for transition class or group, equivalent to how we would do it in SDA, like a parameter to .startViewTransition<br>
<emilio> s/SDA/SPA<br>
<fantasai> noamr: in this case, we can't have other descriptors for URL origin for navigation type<br>
<fantasai> noamr: because they would interfere with each other<br>
<fantasai> noamr: that's why I want outside the braces, as part of pseudo-classes<br>
<fantasai> noamr: If this is a back navigation, use this transition<br>
<fantasai> noamr: if it is a ???, then don't allow cross-origin<br>
<fantasai> noamr: It needs to be outside so we can style navigations based on it<br>
<fantasai> noamr: so what's outside is the navigation type and origin, and inside is only the mechanism<br>
<fantasai> noamr: something that shouldn't affect the styling, but only be a trigger boolean opt in<br>
<Rossen_> ack noamr<br>
<Rossen_> ack khush<br>
<fantasai> khush: Question for fantasai and emilio<br>
<fantasai> khush: You mentioned you don't like idea of media query or pseudo-class<br>
<fantasai> khush: but if I want to add a view transition class name based on what type of transition it is<br>
<fantasai> khush: how would I go about doing that?<br>
<fantasai> khush: either can specify any CSS rule, or ...<br>
<fantasai> khush: any suggestion other than MQ or pseudo-class? How would they specify different `view-transition-name`?<br>
<fantasai> <fantasai> Good question... I don't have a good answer.<br>
<fantasai> Rossen_: Doesn't seem we're ready for resolution, but getting some sense of direction<br>
<fantasai> Rossen_: Seems like it should continue in the issue<br>
<fantasai> khush: Can take to issue<br>
<fantasai> khush: What I'm stuck on is what CSS concept to use on customization<br>
<fantasai> khush: If someone could put some thoughts, that would help move the issue forward<br>
<khush> Thank you!<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8048#issuecomment-1671755964 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 9 August 2023 16:28:02 UTC