- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 13 Dec 2023 19:54:55 -0500
- To: www-style@w3.org
========================================= These are the official CSSWG minutes. Unless you're correcting the minutes, Please respond by starting a new thread with an appropriate subject line. ========================================= Scroll Animations ----------------- - RESOLVED: Add 'all' keyword to 'timeline-scope', equivalent to specifying all possible names (Issue #9158: Add a way for timeline-scope to pull up all contained timelines) - RESOLVED: Add 'scroll' named range to view timelines, represents entire scroll range, bikeshed keyword in issue (Issue #9367: Range for entire scroll range) - RESOLVED: Any position within the overlarge snap area is a valid snap position, as defined in the (clarified) spec (Issue #6863: Difficult to use snap areas which are larger than the scrollport) CSS Images & Grid ----------------- - RESOLVED: fr values in stripes() convert to max(0, 100% - sum-of-percents - sum-of-fixed) * flex value / max(1, sum-of-flexes) (a <length-percentage>) when needed for interpolation (Issue #8622: Allow transitions between different types within `stripes()`) CSS Animations -------------- - RESOLVED: Draft up this proposal into css-animations-2, come back to WG for review (Issue #8942: Add animation-trigger for triggering animations when an element is in a timeline's range) ===== FULL MEETING MINUTES ====== Agenda: https://lists.w3.org/Archives/Public/www-style/2023Dec/0002.html Present: Rossen Atanassov Tab Atkins-Bittner David Baron Stephen Chenney Yehonatan Daniv Elika Etemad Robert Flack Jonathan Kew Alan Stearns Miriam Suzanne Bramus Van Damme Chair: astearns Scribe: fantasai Scribe's scribe: TabAtkins Scroll Animations ================= Add a way for timeline-scope to pull up all contained timelines --------------------------------------------------------------- github: https://github.com/w3c/csswg-drafts/issues/9158 bramus: This issue is about declaring many animation timelines and using broader scope bramus: This issue is about using "all" for hoisting them up bramus: Allow also anchor name for hoisting up using anchor scope flackr: Can a timeline be pulled up with multiple scope? fantasai: No. fantasai: The 'all' keyword traps all the keywords, just like individual keywords trap those keywords fantasai: might be useful if you want to encapsulate flackr: ok Rossen: Any other concerns? bramus: Proposed to add "all" which will pull up all timelines <fantasai> (It's basically the same as specifying all possible names) <schenney> The concern raised by flackr is already in the issue, raised by https://github.com/w3c/csswg-drafts/issues/9158#issuecomment-1742797028 YehonatanDaniv: If I name something in a descendant, and then specify all in an ancestor, what happens? flackr: The lower scope captures that name, it won't be pulled higher up RESOLVED: Add 'all' keyword to 'timeline-scope', equivalent to specifying all possible names CSS Images & Grid ================= Allow transitions between different types within `stripes()` ------------------------------------------------------------ github: https://github.com/w3c/csswg-drafts/issues/8622 <fantasai> -> https://github.com/w3c/csswg-drafts/issues/8622#issuecomment-1758136484 TabAtkins: Currently, in stripes() you can write widths as length, percentage, or flex TabAtkins: We didn't have interpolation behavior for between flex and lengths TabAtkins: but in this context, the flex definition is very straightforward and can be expressed in terms of percentages and lengths TabAtkins: So my proposal was that each flex in a stripes function will compute to a particular expression TabAtkins: which makes it into a <length-percentage> <TabAtkins> max(0, 100% - sum-of-percents - sum-of-fixed) * flex value / max(1, sum-of-flexes) TabAtkins: and then you can transition that with all the other length-percentages just fine fantasai: Makes sense. Do we store fr as computed value? fantasai: Or do we compute through to <length-percentage> only when interpolating TabAtkins: It's best for authors to leave fr's as they are, unless they need to convert for an interpolation <flackr> +1 <fantasai> +1 TabAtkins: [explains the formula] flackr: I like converting just-in-time flackr: We do this with other types when interpolating RESOLVED: fr values in stripes() convert to max(0, 100% - sum-of-percents - sum-of-fixed) * flex value / max(1, sum-of-flexes) (a <length-percentage>) when needed for interpolation Scroll Animations Con't ======================= Range for entire scroll range ----------------------------- github: https://github.com/w3c/csswg-drafts/issues/9367 flackr: We decided that the default range for 'view' timelines is the 'cover' range, because this is a sensible default animation flackr: for animating as some element goes through the viewport flackr: but no way to express the total scroll range flackr: so sometimes might want start of scroll to some position in view range flackr: or view range position to end of scroll flackr: simplest think we could do is add a named range that refers to the full scroll range, so we can refer to it in the animation-range flackr: suggestion is "full" flackr: Also raised issue specifying pixel values as offsets from cover range flackr: but might be awkward flackr: also would be a breaking change flackr: to change interpretation of values without range name flackr: because default animation range for view timelines is 'cover' bramus: If you specify 3 values, if you don't specify a range name it defaults to 'cover' for view timeline and 'full' for scroll timelines? flackr: I thought we already resolved 3-value syntax fantasai: I'm trying to think through this fantasai: Not sure "full" is actually better than "scroll" fantasai: View timelines are supposed to be about when the element is in view, there's different interps of what that might mean, but that's what it's about fantasai: Saying "full" timeline is the entire scroll range might be a little odd fantasai: If you wanted the full scroll range you should use the scroll timeline rather than view timeline fantasai: I can see use-cases for wanting one end or another tied to the end of the scroll fantasai: But we should make it clearer you're extending outside the conceptual range of the view timeline fantasai: And it definitely shouldn't be the default flackr: Originally why I proposed 'scroll', full range of view timeline should be considered to be 'cover' bramus: If we use 'scroll', then it wouldn't make sense for other timelines e.g. media playback timelines flackr: For media timelines, default would be the full playback range bramus: For scroll timelines, default is the full scroll timeline schenney: "full" is referring to "full page", might help to clarify flackr: Not quite, talking about entire scroll range schenney: Complete scrollable area? flackr: Yes Rossen: That excludes the scroll-margin areas? flackr: I don't think so, it represents offset zero and max offset Rossen: If I have something in the negative space? flackr: Yes, that's excluded Rossen: And something beyond end of range? flackr: Right fantasai: Do we want to accept and bikeshed later? Rossen: Let's pick one of the two names for now, and then go with it <schenney> content? Rossen: Let's stick to 'scroll' because then at least one person doesn't like it, and we can bikeshed to find the right name Rossen: Proposed to add 'scroll' named range to view timelines, represents entire scroll range RESOLVED: Add 'scroll' named range to view timelines, represents entire scroll range, bikeshed keyword in issue Difficult to use snap areas which are larger than the scrollport ---------------------------------------------------------------- github: https://github.com/w3c/csswg-drafts/issues/6863 flackr: fantasai and Tab both commented that the intention is what I am asking for flackr: [describes issue] flackr: I'm seeing a lot of support for that sentiment in the issue flackr: I think we're resolving that the updated spec is good, with expected behavior [reviewing the comments in the issue] fantasai: Tab's comment isn't correct, intention of spec was that any position within the overlarge snap area would be a valid place to rest <fantasai> current spec -> https://drafts.csswg.org/css-scroll-snap-1/#snap-overflow flackr: I think the current spec is good PROPOSED: any position within the overlarge snap area is a valid snap position, as defined in the (clarified) spec RESOLVED: Any position within the overlarge snap area is a valid snap position, as defined in the (clarified) spec CSS Animations ============== Add animation-trigger for triggering animations when an element is in a timeline's range --------------------------------------------------------------------- github: https://github.com/w3c/csswg-drafts/issues/8942 flackr: Common use case for scroll-based animations flackr: is to have a time-based animation that starts at a certain scroll position flackr: In this issue, proposing a property that controls the playback of a time-based animation based on the scroll position flackr: leveraging the fact that we can define positions in scroll position using scroll timelines flackr: so using one timeline (Scroll timeline), control play state of another animation on another timeline (time) flackr: We have a proposal that tries to capture the various use cases flackr: We have a new property, I'm calling 'animation-trigger' flackr: associated with corresponding animation entry flackr: Second value is behavior, come back to that later flackr: then you specify 2 ranges: range in which you activate the animation, and range in which you de-activate the animation flackr: Behavior has 3 values, one for one-shot animation flackr: it never runs again after you trigger flackr: Alternate is plays when entering, and reverses when you enter exit range flackr: Final is cancelled [missed] flackr: As I say this, I'm realizing that one-shot can be represented with exit range being the entire scroll range <bramus> Demos for each range, using a (quick) polyfill: https://github.com/w3c/csswg-drafts/issues/8942#issuecomment-1853045701 fantasai: That might be confusing though YehonatanDaniv: We started with view timeline, actually YehonatanDaniv: Scroll is also an option because no limit YehonatanDaniv: Ranges are against a view timeline of the element flackr: They're the ranges of the timeline that you specified, whichever you specified dbaron: I felt I only sort-of followed the descriptions of 3 values dbaron: Does one of those values let you do something where as you scroll down, it plays forward, and if you scroll up it plays backwards? flackr: That's the 'alternate' value flackr: which reverses the value when you leave the range flackr: I have a demo bramus: I have a bunch of tests to demo the various behaviors bramus: Also built some demos for more real-world use cases bramus: such as stick element that animates as stuff enters/leaves scrollport bramus: I could achieve everything I wanted with the options bramus: but not ergonomic, if you use 'once' you just need to specify where it triggers bramus: For alternate need t2, and for repeat you need all 4 bramus: depending on the second value might need 1-4 values bramus: A bit confusing fantasai: First comment, I think maybe consider some longhands fantasai: Second, maybe we want to draft this up so that it's a bit more clear what the proposal is YehonatanDaniv: Another keyword that was proposed for toggling play state of animation YehonatanDaniv: for animations that play indefinitely flackr: Yes, one use cases not handled was if you want the animation to just pause outside the range and continue when you re-enter the range Rossen: Do we have a proposed path forward? flackr: Let's write something up in spec-ese, and come back PROPOSED: Draft up this proposal into css-animations-2, come back to WG for review RESOLVED: Draft up this proposal into css-animations-2, come back to WG for review
Received on Thursday, 14 December 2023 00:55:28 UTC