- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 25 Oct 2023 16:28:38 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-view-transitions-2] Decide on naming for navigation-triggered view-transition rule`, and agreed to the following: * `RESOLVED: take the descriptors in the at-rule block` <details><summary>The full IRC log of that discussion</summary> <bramus> noamr: continuation of TPAC convo about opt-in for VT on navigation<br> <bramus> … we need to name it, and be clear how to extend int he future<br> <bramus> … also worked with dbaron on this (thanks!)<br> <bramus> … see the original post for code<br> <bramus> … VT on navigation can be extended to a few diffferent parts<br> <bramus> … 1 is name of the feature<br> <bramus> … i call it “navigation-view-transition”<br> <bramus> … other one is, if there any nav-performed VT, the way it can be extended is which navs does it supply to?<br> <bramus> … from article to home?<br> <bramus> … also type o fnavigation (reload, back, etc)<br> <bramus> … so that is the first 2 things<br> <bramus> … other one is “is this nav going to trigger a VT or not?” which is sort of a boolean you could say<br> <bramus> … we might want to say it is, and then override with MQ (see example)<br> <bramus> … from article to home it is one, but with a back navigation is off<br> <bramus> …last thing is to extend for types. you can set a few idents to that classify the transition type and then use that in selectors<br> <bramus> … elika proposed to also have the conditionals for navigation inside the rule<br> <bramus> … which is also an option<br> <bramus> … i think the conditional should b e outside (cfr. media query) but it is debatable<br> <Rossen_> ack fantasai<br> <bramus> fantasai: I tweaked the examples in the issue, so reload<br> <bramus> … given conditioanals can be failry complicated: type, whereto, … – trying to cram that in the at-rule prelude is gnarly<br> <bramus> … font is kinda a different concept: it is declaring a bunch of props that go together to define a conceptual font<br> <bramus> … might make sense to take that mental model here<br> <bramus> … define a transition with type+condition+etc as one package<br> <bramus> … you end up with a pile of these, and take the last one that matches<br> <bramus> … in terms of checking for navigation type (fwd, back, etc) is one thing, then there is also a URL-pattern scenario which can be a long list<br> <emilio> q+<br> <bramus> … shoving all that in the prelude is going to be a mess I think<br> <khush> q+<br> <bramus> astearns: OK, I see the problem you are outlining<br> <bramus> noamr: proposal is to have a VT but no boolean but to say which navs trigger it and have a from-to and perhaps a list of types<br> <astearns> s/astearns/Rossen_ /<br> <bramus> Rossen_: I see<br> <Rossen_> q?<br> <bramus> fantasai: that resolves the awkwardness i thiknk<br> <Rossen_> acm emilio<br> <bramus> emilio: elika’s proposal sounds elegant. we are fine with not combininig different transition blocks<br> <bramus> … we need to define an order, but one of them will match<br> <bramus> fantasai: yeah, they should not cascade into each other<br> <noamr> q+<br> <bramus> emilio: if you ahve different types (e.g reload then do this), my understanding was that the types would be added together<br> <bramus> … with this proposal they would not?<br> <bramus> fantasai: yeah. if you cascade them together you have a very big complex list.<br> <bramus> … for navigating from there to here you don’t want to do ???<br> <bramus> … combining multiple types should be fine (cfr classes); i dont think they should cascade together<br> <bramus> emilio: sgtm<br> <Rossen_> ack khush<br> <Rossen_> ack emilio<br> <emilio> ack emilio<br> <bramus> khush: the qualifiers after the at-rule, i wast hinking of them as a pseeudo-class that activates or not and depending on that the at-rule applies<br> <bramus> … vs things inside the at-rule is what th eauthor is supplying<br> <bramus> … if from and to are descriptors in the at-rule, is the mental model still the same?<br> <bramus> … ???<br> <bramus> fantasai: from grouping at-rules, the conditioanls are on the outside yes<br> <bramus> … other at-rules less strict, e.g. font-face<br> <bramus> … the pile of properties that define the thing go in the block<br> <bramus> … for VT this is something similary: navigation-vt has a bunch of info: url patterns, type of navigation, etc<br> <bramus> … the UA should figure out which one that matches<br> <bramus> … from the bottom up (i.e. last one wins)<br> <emilio> q+<br> <bramus> khush: sounds like ??? which one matches latst value and apply that. we are thinking the same on this. if i try to read these values in JS, what from value would I read?<br> <bramus> fantasai: might be nicer to read here: vtRule.from or vtRule.navigation or … i think this is easier as they are individual declarations<br> <bramus> … they have accessors to each<br> <bramus> Rossen_: let’s go over qeuue now<br> <Rossen_> ack noamr<br> <bramus> noamr: I like the idea, aligning with font-face is probably better than aligning with at-page<br> <fantasai> s/grouping at-rules/grouping at-rules, which contain style rules inside them,/<br> <bramus> … i don’t know what the off-value would be. maybe `navigation: none`?<br> <bramus> … i can see how this would work<br> <Rossen_> ack dbaron<br> <bramus> dbaron: im ok with it but want to call out one thing about analogy to font-face<br> <bramus> … f-f rules are building up a dictionary or library that is then examinded by the font matching algo<br> <bramus> … (explains)<br> <bramus> … i am still ok with something that looks like it<br> <Rossen_> ack emilio<br> <bramus> emilio: if we go with condition in prelude or inside, we need to decide how complex it would be<br> <bramus> … for simple conditions the prelude looks simpler, but many conditions seems easier in the block<br> <bramus> … there could be 4 or 5 conditions<br> <bramus> q+<br> <TabAtkins> +1 to emilio. Putting a name, or *one* type of check (a selector, a MQ, etc), in the prelude makes sense. More than that, keep things in the body for better syntax.<br> <bramus> … i think i prefer fantasai’s proposal<br> <Rossen_> ack fantasai<br> <bramus> fantasai: to respond to dbaron: it is a good analogy. most ??? are conditional. the content you are pulling in is the src descriptor. font-style and font-weight are just conditionals. basically doing the same here.<br> <TabAtkins> (I think @font-face *should* have put its family name in the prelude, but oh well, it was one of our first at-rules and we didn't have a consistent design yet.)<br> <TabAtkins> s/???/declarations in the block/<br> <TabAtkins> scribe+<br> <fantasai> (Yeah, agreed, I'd have put font-family in the prelude also. But anyway...)<br> <TabAtkins> bramus: If you put it in the prelude, you can most likely nest the various at-rules, which isnt' possible with a big block<br> <Rossen_> ack bramus<br> <TabAtkins> bramus: So if you want to change one param you have to duplicate everything and change one value<br> <bramus> Rossen_: sounds like most ppl are agreeing …<br> <khush> q+<br> <bramus> … should we take resolution?<br> <Rossen_> ack khush<br> <bramus> khush: fine with going the suggestion by fantasai. would be nice to take 2 separate resolutions: 1/ descriptors in at-rule block, 2/ names of things<br> <bramus> PROPOSED RESOLUTION: take the descriptors in the at-rule block<br> <bramus> RESOLVED: take the descriptors in the at-rule block<br> <bramus> Rossen_: names should be bikeshed?<br> <bramus> noamr: maybe resolve on current names? navigation: auto | none and the type<br> <khush> q+<br> <Rossen_> ack khush<br> <bramus> khush: `navigation-name` for the nav type? dont thikn we need that righ tnow<br> <bramus> noamr: idea is we dont have all of them. right now would be a boolean (auto or none) which can be extended in the future<br> <bramus> khush: rathe rnot name that navigation<br> <bramus> … (missed)<br> <bramus> Rossen_: let’s take back to the issue<br> <bramus> noamr: OK<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9383#issuecomment-1779644377 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 25 October 2023 16:28:40 UTC