- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 14 Sep 2023 16:13:25 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-view-transitions-2] Declarative opt-in for cross-document navigations`, and agreed to the following:
* `RESOLVED: Accept the final syntax proposal.`
<details><summary>The full IRC log of that discussion</summary>
<noamr> https://github.com/w3c/csswg-drafts/issues/8048#issuecomment-1716035713<br>
<TabAtkins> noamr: Same as previous, I posted a comment that summarized current thinking and has some HAQs<br>
<TabAtkins> noamr: this is about cross-document VT<br>
<TabAtkins> noamr: the way we look at this, it's a conditional dependency<br>
<TabAtkins> noamr: An if() statement that's called twice, once when you leave the old doc, and once when you're ready to render the new doc<br>
<TabAtkins> noamr: when this event happens we want to check the conditions are met<br>
<TabAtkins> noamr: Some are environmental, like from MQ or supports, others are conditions about navigation itself<br>
<TabAtkins> noamr: Sematnically this could mean "are we moving from 'play' page to 'song' page"<br>
<TabAtkins> noamr: If conditions are met we want to start the VT, as if we were in JS. On the old page that means capturing the state of the old document and magically passing it along to the new one.<br>
<TabAtkins> noamr: So on the new page if we successfully opted in, we start the VT with the stuff we captured from the old doc<br>
<TabAtkins> noamr: And w'ell pass the transition types that we just talked about<br>
<TabAtkins> noamr: So if going between a playlist and song page, this is an "expand" transition<br>
<TabAtkins> noamr: So these are ways to declaratively map what VT is taking place<br>
<TabAtkins> noamr: We're thinking of the whole thing as a transition behavior that's activated from a navigation<br>
<TabAtkins> noamr: As we decided in last f2f we wanted a new at-rule<br>
<TabAtkins> noamr: Currently called @navigation<br>
<TabAtkins> noamr: First cross-document thing in CSS, exciting<br>
<TabAtkins> noamr: Details all in the comment<br>
<TabAtkins> noamr: We qualify the navigation in some way<br>
<TabAtkins> noamr: Inside of it we ahve descriptors, like font descriptors.<br>
<TabAtkins> noamr: view-transition-behavior, and which type names are passed along<br>
<TabAtkins> noamr: There was a q from elika yesterday why we went with a name like "same-origin", or why it has to be urls<br>
<TabAtkins> noamr: We really dug into this quite deep<br>
<TabAtkins> noamr: The first proposal in this sapce was we parse both docs, and they each declare what type they are<br>
<TabAtkins> noamr: Doc A could say it's "playlist" and doc b could say it's "song", but that's complicated, you have to know what the new page is before you can unload the old page, which is too hard to do right<br>
<TabAtkins> noamr: Second option was controller based<br>
<TabAtkins> noamr: To decide based on what link was clicked<br>
<TabAtkins> noamr: Too limiting, sometimes you click the back button. Sometimes you want a transition from a `location.href` mutation<br>
<TabAtkins> noamr: So clicking is too limiting<br>
<TabAtkins> noamr: All we ahve left is URLs<br>
<TabAtkins> noamr: They're the one thing we're guaranteed to have in cross-document navigation<br>
<TabAtkins> noamr: So we qualify these by URLs, it's the only thing we can do as far as we can tell.<br>
<TabAtkins> noamr: Reason why we put same-origin there by default is we dno't support cross-origin or same-site yet, for various reasons.<br>
<TabAtkins> noamr: We wanted, for the reader, for it to be clear that this is a same-origin navigation. Later it's expandable to various things like urlpattern<br>
<TabAtkins> noamr: Or qualifying with back/reload/etc navigation types<br>
<TabAtkins> noamr: We were asked for what kinds of things we expect to see in the future<br>
<TabAtkins> noamr: We expect same things that exist in Navigation API. Type, URL, and incoming/outgoing url<br>
<TabAtkins> noamr: So anything that could go into startViewTransition() could go here<br>
<TabAtkins> noamr: Names of types go into sVT(), so they go here. Future args also go here.<br>
<TabAtkins> noamr: If we do anything like mixins it'll reflect here<br>
<TabAtkins> (Unsure what is meant by "mixins" here but I dont' think it's important)<br>
<TabAtkins> noamr: We also have something called "navigation" here, pretty general<br>
<TabAtkins> noamr: We didn't think building into @supports or anything was appropriate<br>
<TabAtkins> noamr: Also questions about and/or here<br>
<TabAtkins> noamr: Okay to not resolve that yet, just general behavior.<br>
<TabAtkins> noamr: If our vision of declarative nav transitions makes sense, even if we don't resolve on details now, just want to validate that the syntax is extendable in this way<br>
<TabAtkins> astearns: Just as a scoping thing, I think it's great to look at future extensions of the syntax, so thanks for htat<br>
<TabAtkins> astearns: All you're asking for resolution on for now is @navigation with those descriptors, and only same-origin?<br>
<TabAtkins> noamr: Just the same-origin descriptor, and the vt class names that we just resolved on<br>
<TabAtkins> noamr: For more behavior, we'll wait to resolve those generally<br>
<eeeps> q+<br>
<astearns> ack fantasai<br>
<TabAtkins> fantasai: I think we do need to have a good sense of the whole package and decide this looks good in general<br>
<zcorpan> q+<br>
<TabAtkins> fantasai: Just don't want us to decide on something, ship it, and then it looks awkward or doesn't actually expand as we needed.<br>
<TabAtkins> fantasai: So just want to make sure this is what we want to do<br>
<TabAtkins> fantasai: I have concerns with urlpatterns. Generally we're opaque to what url you actually are.<br>
<TabAtkins> fantasai: Some features where we're breaking that<br>
<TabAtkins> fantasai: But for something like this, you need full regex to capture these<br>
<noamr> q+<br>
<TabAtkins> fantasai: Like for a blog, recognizing a date in the url, etc<br>
<noamr> URL patterns contain regular expressions<br>
<TabAtkins> fantasai: And that won't work for websites with random ids<br>
<TabAtkins> fantasai: I understand th eproblems with pages defining their own classes; I don't have a great answer<br>
<TabAtkins> astearns: Noam's response is that urlpatterns do contain regexes<br>
<fantasai> TabAtkins: URL patterns are being developed elsewhere for a lot of other use cases, we just need a subet<br>
<fantasai> TabAtkins: I think it's fine<br>
<fantasai> TabAtkins: While I also agree it's probably a bit awkward, it seems like the best way forward afaict<br>
<TabAtkins> astearns: And whether or not that's correct, I think we can shoehorn *something* that does this matching between URLs into this at-rule later<br>
<fantasai> TabAtkins: current extensability plan in the comment seems reasonable<br>
<astearns> ack eeeps<br>
<TabAtkins> eeeps: Is there time to wait for *anything* from the second doc? Like an http header, or an early <meta>?<br>
<TabAtkins> eeeps: Or is there just no way to keep the outgoing doc alive<br>
<TabAtkins> noamr: We can keep it alive for a bit, and this can be a future extension to the rendering model<br>
<TabAtkins> noamr: But we don't want to rely on it for how transitions are defined. It's kinda an advanced, complicated addition to the web platform.<br>
<TabAtkins> noamr: It's like prerendering but more<br>
<TabAtkins> noamr: So actually quite complicated to do right and cross-browser<br>
<TabAtkins> noamr: So don't want to rely on it for now. Can be a future UX enhancement.<br>
<TabAtkins> eeeps: So the incoming URL really is the only thing you can rely on from the incoming page, so far<br>
<TabAtkins> noamr: correct<br>
<TabAtkins> astearns: And this can be a future discussion since we're not resolving on that bit today<br>
<astearns> ack zcorpan<br>
<TabAtkins> zcorpan: syntax q about urlpattern<br>
<TabAtkins> zcorpan: I think it's a string? URLs can conflict with CSS syntax.<br>
<khush> q+<br>
<fantasai> TabAtkins: absolutely. Never want to repeat the unqouted URL mistake again<br>
<TabAtkins> TabAtkins: Oh yeah we're never repeating the "unquoted urls" problem again, I didn't notice that.<br>
<astearns> ack noamr<br>
<astearns> ack fantasai<br>
<Zakim> fantasai, you wanted to comment on the classifying links idea<br>
<TabAtkins> fantasai: you mentioned the idea of changing the transition based on which link you clicked. that sounds like something people might want<br>
<TabAtkins> fantasai: would be something to consider, i guess would override this general routing<br>
<TabAtkins> fantasai: Also, I think it would be more udnerstandable if this wasn't named generically "@navigation". Would be clearer what it's for, wouldn't have to repeat "view-transition" in each thing.<br>
<TabAtkins> noamr: Yeah, qualifying a transition by the "controller" (link clicked) is osmething we lik ein general, it's just a different feature<br>
<fantasai> and more clearly a separate namespace as e.g. 'view-transition-name'<br>
<TabAtkins> noamr: So you can cusotmize by URL and by "last-active" link (Bramus' term)<br>
<TabAtkins> noamr: I think those can be taken separately without conflict, we're on the sam epage<br>
<TabAtkins> noamr: Reason I wanted to call it @navigation, two reasons but not integral<br>
<TabAtkins> noamr: First it's a qualified navigation, not a qualified VT. Sounds wierd to say "same origin view transition"<br>
<TabAtkins> noamr: Also sounds a bit funky to have "view transtion between these url patterns"<br>
<TabAtkins> noamr: Also we envision this being general navigation customization later. If you want to hold the page for a little bit while loading the new one, that's a generic feautre, not VT-specific.<br>
<TabAtkins> noamr: Also if we want to disallow UA transitions, this is a good way to do it.<br>
<TabAtkins> noamr: Like swipe UI<br>
<TabAtkins> noamr: So that's why we think a generic name is better<br>
<astearns> ack khush<br>
<TabAtkins> noamr: But we're also okay with saying "don't try to solve those future cases yet"<br>
<fantasai> I think disabling UA transitions fits fine into an @view-transitions or @page-transitions rule<br>
<TabAtkins> khush: Right now you say "same-origin"<br>
<TabAtkins> khush: If you later have urls, "same-origin" is the same as a very general URL<br>
<noamr> I kind of like @page-transitions<br>
<noamr> q+<br>
<TabAtkins> khush: I think I convinced mysefl against this, never mind<br>
<fantasai> I kind of do too, except now I'm wondering if that might conflict with paged media page turn transitions :)<br>
<fantasai> if we ever go there<br>
<TabAtkins> khush: Also, the old document can be held, until you have a response header that says the navigation will be successful<br>
<fantasai> could do @nav-transition<br>
<TabAtkins> khush: that's the extent of info we have for now that we can provide to the old document<br>
<fantasai> (we already abbreviation navigation to nav in the nav-properties)<br>
<zcorpan> I don't like @page-transition because it sounds like it's related to @page<br>
<astearns> ack noamr<br>
<TabAtkins> agree, zcorpan<br>
<TabAtkins> noamr: Some name bikesheds in IRC<br>
<TabAtkins> noamr: Suggestion was "@page-transition", we have a "pageTransition" event in JS that is exactly this sort of thing.<br>
<TabAtkins> noamr: But elika mentioned something about wanting to do a paged-media transition at some point, I'm not sure I udnerstand that.<br>
<TabAtkins> zcorpan: Yeah but the existing @page is what clashes<br>
<fantasai> we already have named pages in pagd media, so actually defining classes of transitions would be pretty straightforward...<br>
<TabAtkins> astearns: REason to not use @view-transition?<br>
<TabAtkins> noamr: Just think this is qualifying the navigation, not the view-transition.<br>
<TabAtkins> zcorpan: You can do a view-transition without a nav, but this only does navigation VTs. So just "@view-transition" seems incorrect<br>
<astearns> that makes sense<br>
<TabAtkins> miriam: Is there a chance in the future that all VTs could be controlled here?<br>
<TabAtkins> noamr: For @auto-view-transition, I think it could maybe be trigger by the Navigation API automatially<br>
<zcorpan> @auto-view-transition-on-navigation<br>
<TabAtkins> noamr: One thing is we can call it @view-transition or @auto-view-transition, and then call the descriptor `trigger`, with values "navigation" or "none"<br>
<TabAtkins> astearns: I think we have objections to @navigation, and anything with @page-*<br>
<TabAtkins> astearns: We have @view-transitions or @auto-view-transitions<br>
<TabAtkins> astearns: Other options?<br>
<TabAtkins> khush: Why the "auto"?<br>
<bramus> q+<br>
<astearns> ack bramus<br>
<TabAtkins> noamr: To make it clear this doesn't control VTs in general, specifically only those that are auto-created by the UA.<br>
<TabAtkins> bramus: At the previous f2f I floated @config, it's super generic and could maybe apply here.<br>
<zcorpan> @view-transition { trigger: navigation; ... } seems ok<br>
<khush> +1<br>
<TabAtkins> TabAtkins: One of the objections to @navigation was it was too generic, so going even more generic seems unlikely to work<br>
<zcorpan> @view-transition same-origin { trigger: navigation; ... }<br>
<noamr> @view-transition { trigger: navigation }<br>
<noamr> @view-transition same-origin { trigger: navigation }<br>
<fantasai> if it's not triggered by navigation, does same-origin still make sense?<br>
<TabAtkins> noamr: Another thing we put to the side is we want this rule to be nestable in MQ<br>
<khush> the other keyword trigger takes is "none".<br>
<fantasai> TabAtkins: The moment a navigation happens is when you figure out when it happens<br>
<fantasai> TabAtkins: having it be conditional on MQ makes sense<br>
<TabAtkins> astearns: I think that's neough bikeshedding for today. Suggest we resovle on Noam's proposal in IRC, we can bikeshed later.<br>
<TabAtkins> astearns: Any objection to `@view-transition same-origin { trigger: navigation | none; }`<br>
<TabAtkins> RESOLVED: Accept the final syntax proposal.<br>
<TabAtkins> fantasai: Wondering if the prelude and trigger should swap places. Unsure what `trigger: none` would do.<br>
<TabAtkins> astearns: In interest of time, I suggest opening an issue for that.<br>
<zcorpan> none would do nothing<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-1719751618 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 14 September 2023 16:13:28 UTC