- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 14 Sep 2023 15:39:15 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-view-transitions-2] Syntax for customizing transitions based on their type`, and agreed to the following: * `RESOLVED: Add a 'TBD' argument to startViewTransition that takes a list of CSS identifiers, allow them to match against a pseudo-class which accepts a comma-separated (or) list of view transition names during which it matches` <details><summary>The full IRC log of that discussion</summary> <noamr> Summary: https://github.com/w3c/csswg-drafts/issues/8960#issuecomment-1708702647<br> <TabAtkins> noamr: I posted a summary content for where we've gotten to and what the proposal is<br> <TabAtkins> noamr: We also gave a summary in general of VT yesterday<br> <TabAtkins> noamr: This is a continuation from the f2f a few months ago<br> <TabAtkins> noamr: With a single document with many VTs possible - think of a spotify that can slide-transition between main pages, and a different between a played song where it expands<br> <TabAtkins> noamr: So we want a way to say "don't take everything from the page that can transition", but rather name the type of transition and pick and choose which elements go with what<br> <TabAtkins> noamr: So far the way to do it is modifying the DOM: put a class on <html> that you use in a selector to set v-t-name<br> <TabAtkins> noamr: Some issues, using DOM as ephemeral state for something that's entirely style<br> <TabAtkins> noamr: Plus when we go later in cross-document, we want a declarative way to do this<br> <TabAtkins> noamr: So we want a notion of cross-frame transitions that's embedded into CSS rather than a general-purpose JS mechanism.<br> <TabAtkins> noamr: Proposed syntax is something that looks and feels like class names<br> <TabAtkins> noamr: We'd pass it together with the v-t<br> <TabAtkins> noamr: Currently it only accepts one parameter, the update callback<br> <TabAtkins> noamr: We suggest another parameter, a list of a transition types<br> <TabAtkins> noamr: like "slide" or "reverse-slide", etc<br> <TabAtkins> noamr: And then have a pseudo-class on whatever's scoping the transition (currently, always <html>), and that matches based on which transition types are activated<br> <TabAtkins> noamr: I want to present the alternative we consdiered, too<br> <TabAtkins> noamr: Which was to qualify the pseudo-elements that are created<br> <TabAtkins> noamr: We thought that wasn't enough, since the transition type also affects which elements are picked for the transition, not just which pseudo-elements are created.<br> <TabAtkins> noamr: The more advanced alternative is we qualify pseudo-element names too.<br> <TabAtkins> noamr: That's possible, but felt limiting.<br> <TabAtkins> noamr: Perhaps you want to hide something in the page while the transition is going on, it' snot necessarily participating in the transition.<br> <vmpstr> q?<br> <TabAtkins> noamr: So we felt there's not much reason to avoid our preferred solution, and the other ways are all limited.<br> <TabAtkins> +1, this sounds good<br> <vmpstr> TabAtkins: i like this idea, and sounds reasonable. official cases brought up with things that don't participate makes sense<br> <khush> q+<br> <astearns> ack khush<br> <TabAtkins> khush: I prefer "type" over class names<br> <fantasai> +1<br> <noamr> q+<br> <TabAtkins> khush: because there's another feature request where people want to apply styles to some pseudos<br> <TabAtkins> khush: right now you can either do all ::v-t-group() or one with a particular name, can't do just some in a group<br> <vmpstr> q+<br> <TabAtkins> khush: Second is "and" vs "or"<br> <TabAtkins> khush: keeping the same syntax as proposed here seems good<br> <astearns> ack fantasai<br> <TabAtkins> fantasai: I agree with khushal that using classes seems tied into html classes, seems confusing. "type" seems fine.<br> <eeeps> lea: https://github.com/w3c/csswg-drafts/issues/8960<br> <TabAtkins> fantasai: Another q, when you specify multiple names in the pseudo-class, is that "and" or "or". If it's "or" you should use a comma.<br> <TabAtkins> fantasai: Overall a good approach.<br> <astearns> ack noamr<br> <TabAtkins> noamr: I thought "types" were a bit [missed], it describes something nominal<br> <TabAtkins> noamr: But im' fine with that<br> <TabAtkins> noamr: For "and" vs "or", we thought of spaces meanin "and" and commas meaning "or"<br> <khush> sounds good<br> <fantasai> +!<br> <fantasai> s/!/1/<br> <TabAtkins> TabAtkins: Other option is we just do neither and rely on selector syntax to handle and/or<br> <TabAtkins> TabAtkins: Depends on how common we think selecting on multiple names will be<br> <ydaniv> q+<br> <TabAtkins> astearns: That would also be more compatible with future development<br> <TabAtkins> noamr: Yeah, that's a possibility<br> <TabAtkins> vmpstr: Comment about the name<br> <fantasai> ... It's a reallllly long pseudo-class name, let's not make people type out that much for simple booleans :)<br> <TabAtkins> vmpstr: I prefer "class" over "type" specifically because I think there's a possibility of using this in other contexts like web animations<br> <astearns> could think of and/or as a future extension to solve that pain :)<br> <TabAtkins> vmpstr: This would be able to set a number of additional classes that last for some duration<br> <TabAtkins> vmpstr: In this case the pseudo-class name would have to be in there, so it's not tied to VT<br> <TabAtkins> vmpstr: But if it's specifically "class"... I'm not particularly tied to it but it invokes CSS classes which is what this acts like.<br> <fantasai> TabAtkins: This is basically an automatically-managed class<br> <fantasai> TabAtkins: browser is adding/removing for you<br> <astearns> ack ydaniv<br> <astearns> ack vmpstr<br> <TabAtkins> YehonatanDaniv: The direction is good, if we had a list of types/classes/whatever, I think doing "and" would be more productive<br> <TabAtkins> YehonatanDaniv: But in general having a list of types, this covers the need<br> <TabAtkins> astearns: I had an instinctual yuck against using space/comma to indicate and/or<br> <TabAtkins> astearns: Any strong reason to not use `and` and `or` keywords?<br> <TabAtkins> noamr: No particular reason, jsut consistency with selectors. But that would be consistent with MQs, so.<br> <TabAtkins> noamr: Another idea was to borrow the class selector syntax, so `.page.slide, .foo-slide`<br> <TabAtkins> astearns: How much do you think we can resolve on today?<br> <hober> q?<br> <TabAtkins> noamr: I'd like to say that we'll decide on the name and the and/or syntax later, but the general idea is good.<br> <fantasai> We use commas to mean "or" in several places in functional pseudo-class syntax<br> <TabAtkins> astearns: I'd like to add a specific syntax in the spec if possible<br> <TabAtkins> astearns: If people have concerns about what we chose, they can raise issues.<br> <TabAtkins> noamr: I suggest to resolve for now on "type" and not having and/or syntax yet<br> <TabAtkins> noamr: Since selectors can already do and/or for now.<br> <TabAtkins> khush: If we resolve on this now, will this break if someone makes a VT type named "and"?<br> <TabAtkins> TabAtkins: No, since we'll currently be allowing only one name. In the future if we allow and/or internally, it'll be written ":v-t-type(and and foo)`, which is perfectly unambiguous (to a machine)<br> <ydaniv> q+<br> <TabAtkins> fantasai: we use commas all over selector syntax to mean "or"<br> <noamr> +1<br> <TabAtkins> fantasai: So even if we decide to add boolean keywords later, we'd probably still want commas for consistency with tons of things<br> <TabAtkins> fantasai: So I think we should adopt that in the first iteration as well<br> <astearns> ack fantasai<br> <TabAtkins> +1, it is very natural<br> <astearns> ack ydaniv<br> <TabAtkins> and the "and" selector behavior is shorter<br> <TabAtkins> YehonatanDaniv: So if I get this right, I can specify a few tpes in the startViewTransition() call<br> <fantasai> TabAtkins: They'll all apply<br> <TabAtkins> noamr: So elika do you want space for "and"?<br> <TabAtkins> fantasai: I'm fine with that, I mainly just care about commas for "or"<br> <fantasai> TabAtkins: and might inhibit future syntax design<br> <fantasai> s/and might/"and" might/<br> <TabAtkins> astearns: So it sounds like we have consensus on adding a list of types to VT<br> <TabAtkins> khush: yes<br> <TabAtkins> astearns: and add exapmles for referring to them<br> <TabAtkins> astearns: Objections to list of types?<br> <TabAtkins> vmpstr: Are we specifically calling these "types"?<br> <TabAtkins> fantasai: For the argument we can say "names", editorially we can call them type names or class names or wahtever.<br> <TabAtkins> noamr: Yeah because the name wouldn't occur in CSS<br> <noamr> we use the word "names" as the parameter name in CSS, and that word does not appear in CSS<br> <noamr> sorry, we use the word "names" as the parameter name in JS, and that word does not appear in CSS<br> <TabAtkins> s/name in CSS/name in JS/<br> <fantasai> PROPOSED: Add a 'names' argument to startViewTransition that takes a list of CSS identifiers, allow them to match against a pseudo-class which accepts a comma-separated (or) list of view transition names to match<br> <fantasai> s/to match/during which it matches/<br> <TabAtkins> vmpstr: So clarifying the syntax, there's a distinction between adding the second param to sVT(), which is different from Noam's comment that has a dict<br> <TabAtkins> noamr: We'r enot proposing a second param, we want sVT() to accept *either* a callback or an options bag<br> <TabAtkins> The options will be a callback and the names<br> <TabAtkins> dbaron: Is there a reason not to do a callback followed by an options bag?<br> <TabAtkins> noamr: This is an API design more from Jake; we don't think the update callback is the obvious first param, it was just the only one earlier.<br> <TabAtkins> dbaron: That makes sense.<br> <TabAtkins> zcorpan: Slight concern with "names" as the name. We already have view-transition-name<br> <fantasai> that's a good point<br> <TabAtkins> TabAtkins: I propose that we resolve on the name of the option in two weeks, when we next meet<br> <fantasai> PROPOSED: Add a 'TBD' argument to startViewTransition that takes a list of CSS identifiers, allow them to match against a pseudo-class which accepts a comma-separated (or) list of view transition names during which it matches<br> <TabAtkins> TabAtkins: What's the pseudoclass called?<br> <fantasai> RESOLVED: Add a 'TBD' argument to startViewTransition that takes a list of CSS identifiers, allow them to match against a pseudo-class which accepts a comma-separated (or) list of view transition names during which it matches<br> <TabAtkins> noamr: :active-view-transition()<br> <noamr> https://github.com/w3c/csswg-drafts/issues/8048<br> <TabAtkins> noamr: And we wait for "and" semantic later if needed<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8960#issuecomment-1719695337 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 15:39:18 UTC