Re: [csswg-drafts] [css-scroll-animations] Rethinking declarative syntax for scroll-linked animations (#6674)

The CSS Working Group just discussed `Rethinking delarative scroll-based animations syntax`, and agreed to the following:

* `RESOLVED: Adopt fantasai/miriam's new direction for the declarative side of scroll-linked animations`
* `RESOLVED: Add flackr as editor to scroll-animations, move Majid to Former`

<details><summary>The full IRC log of that discussion</summary>
&lt;TabAtkins> Topic: Rethinking delarative scroll-based animations syntax<br>
&lt;TabAtkins> github: https://github.com/w3c/csswg-drafts/issues/6674<br>
&lt;Rossen_> github: https://github.com/w3c/csswg-drafts/issues/6674<br>
&lt;TabAtkins> miriam: So we were looking at scroll-linked animations (sla) as part of a bigger thing<br>
&lt;TabAtkins> miriam: Was looking at container-based interpolations, and ideally being able to interpolate values *in* the cascade rather than juming out to animations which override everything<br>
&lt;fantasai> See full discussion at https://wiki.csswg.org/ideas/timelines ; this crosses multiple issues<br>
&lt;TabAtkins> miriam: current sla proposal seems JS focused and later ported to CSS, so we wanted to discuss this<br>
&lt;fantasai> (into which we posted pieces of that overal proposal)<br>
&lt;TabAtkins> miriam: Rethinking how we could make sure SLAs, already in prototype, fit into our future plans for animations/inteprolation<br>
&lt;TabAtkins> miriam: several parts<br>
&lt;fantasai> SLA = Scroll-Linked Animation<br>
&lt;TabAtkins> miriam: Animations based on where you are in the scroll position of a container<br>
&lt;TabAtkins> miriam: So 0% - 100%, linked to an animation progress<br>
&lt;TabAtkins> miriam: Proposal is thus for an animation-timeline property (already in the SLA proposal), defaults to auto, but can be given a scroll() function.<br>
&lt;TabAtkins> miriam: Defaults to looking at nearest scrollable ancestor, you can specify what direction you want to listen to.<br>
&lt;TabAtkins> miriam: And can opt to look at root scroller, or a given container's name (specified in another property)<br>
&lt;Rossen_> q?<br>
&lt;TabAtkins> miriam: An alt to that syntax is that instead of a scroll() function, could break out scroll-timeline-* properties<br>
&lt;fantasai> s/another property/container-name property, re-using from the @container query proposal/<br>
&lt;TabAtkins> miriam: Using the function in animation-timeline seemed like a an extensible way to do more timeline types in the same property<br>
&lt;TabAtkins> flackr: Is there a functional difference there? You could specify scroll() or a timeline name in animation-timeline?<br>
&lt;TabAtkins> miriam: right<br>
&lt;TabAtkins> flackr: So even if it is a function, we have the ability to specify other timeline types with a timeline name<br>
&lt;TabAtkins> miriam: So I think that's all handled by the larger proposal for SLA<br>
&lt;flackr> q+<br>
&lt;TabAtkins> miriam: Another thing - wanting to naimate on elements coming in or out of view. These element-based timelines work a little differently<br>
&lt;TabAtkins> miriam: Proposing view-timeline-* properties<br>
&lt;TabAtkins> miriam: view-timeline-name specifies the name of the timeline corresponding to the element coming in or out of view<br>
&lt;TabAtkins> miriam: view-timeline-inset to adjust how quickly it considers itself in view<br>
&lt;TabAtkins> miriam: and view-timeline-fit gives the baseline for where 0% is - start when they start to come into view, or start when fully into view<br>
&lt;TabAtkins> miriam: Also a question for if we need a timeline for that in-between space, between when it start to come into view and is fully in view<br>
&lt;TabAtkins> miriam: In terms of scroll-linnked timelines, were thinking these timelines would be visible to descendants and siblings; scope is attached to descendants of the parent<br>
&lt;TabAtkins> fantasai: One suggestion was to expose it to the whole document<br>
&lt;TabAtkins> fantasai: Coudl do this<br>
&lt;TabAtkins> fantasai: But it's important to resolve name conflicts with closer in the tree, not later in stylesheet or tree<br>
&lt;smfr> q+<br>
&lt;TabAtkins> fantasai: Multiple elements styled with the same timeline name should animate independently<br>
&lt;Rossen_> ack flackr<br>
&lt;fantasai> s/elements/subtrees/<br>
&lt;flackr> https://github.com/w3c/csswg-drafts/issues/4912<br>
&lt;TabAtkins> flackr: We did have use-cases initially with scroll-timeline where author wanted to specify for a certain numer of pixels of scroll (largely for parallax effects, but we had others)<br>
&lt;TabAtkins> flackr: I assume that to do this with the new proposal you'd need an element that corresponded to the number of pixels you want to animate over?<br>
&lt;TabAtkins> flackr: Because the scroll() function is always from 0 to max scroll<br>
&lt;TabAtkins> flackr: And specifying in terms of %s is dependent on layout which is complicated<br>
&lt;TabAtkins> miriam: I don't think we covered that use-case, we'll have to think abou tit<br>
&lt;TabAtkins> smfr: A few things<br>
&lt;TabAtkins> smfr: For animations that run when an element comes into view, there's subtlety what designers want<br>
&lt;Rossen_> ack smfr<br>
&lt;TabAtkins> smfr: Possibly some hysteresis; if you wobble it around the trigger point you want a looser organic feel<br>
&lt;TabAtkins> smfr: So feel designers will want more specific control<br>
&lt;TabAtkins> fantasai: I think you're mixing up scroll-linked and scroll-triggered animations<br>
&lt;TabAtkins> fantasai: SLA, the scroll position *is* the timeline. if you move the scroller it scrubs the animations backwards<br>
&lt;TabAtkins> fantasai: scroll-triggered is a timed animation that triggers when it comes into view<br>
&lt;TabAtkins> fantasai: the SLA in general is not targetting that use-case<br>
&lt;TabAtkins> smfr: I think I've seen examples that are scroll-linked but do have hysteresis<br>
&lt;TabAtkins> smfr: Some Apple pages have things that are linked to scroll position but still not precisely linked<br>
&lt;TabAtkins> smfr: Some time delay<br>
&lt;TabAtkins> flackr: I've seen this too, some examples of animations that are specifically lagged behind the timeline to provide some extra smoothness<br>
&lt;TabAtkins> smfr: So my problem is just making sure it's rich enough to address designer use-cases, or else they'll still just write JS<br>
&lt;TabAtkins> Rossen_: So are your examples addressed more if you have some sort of easing function that is part of the change?<br>
&lt;TabAtkins> Rossen_: So you have some easing between hops?<br>
&lt;TabAtkins> smfr: I don't think easing is enough; I think there has to be some time-based aspect<br>
&lt;smfr> https://www.apple.com/iphone-13-pro/<br>
&lt;TabAtkins> flackr: Could just be a lot of scroll triggers with easing...<br>
&lt;TabAtkins> smfr: Here's an example<br>
&lt;TabAtkins> smfr: There's an image showing the camera bumps, it's somewhat scroll-linked, but then it's sticky...<br>
&lt;TabAtkins> fantasai: We do have the *-inset property, which gives a *spatial* delay<br>
&lt;TabAtkins> flackr: Further down where it says "shoot it, cut it, ship it" seems to be the effect Simon's talkinga bout<br>
&lt;TabAtkins> Rossen_: So we can record Simon's concern in the issue, but I want to kepe the convo moving<br>
&lt;TabAtkins> smfr: Is it possible for an SLA to affect the size of the scrolled content, so we get circularity?<br>
&lt;TabAtkins> flackr: Yes, this has always been the case. We choose to handle it similar to :hover examples<br>
&lt;TabAtkins> flackr: You get the scroll position at the start of the frame, and if you change the size, the next frame will get an updated animation progress.<br>
&lt;TabAtkins> smfr: So that'll be specified in terms of the HTML event loop<br>
&lt;fremy> +1 to what florian just said, I was about to say the same<br>
&lt;fantasai> florian: ...<br>
&lt;fantasai> TabAtkins: Nothing in the spec to that effect, could have it flicker madly under the cursor<br>
&lt;Rossen_> q?<br>
&lt;florian> s/.../seems a little worse than :hover, as it can loop without further user interaction/<br>
&lt;TabAtkins> flackr: Back to the lag thing, we could have something like transitions where the animation progress eases over time rather than immediately updates. WE'd have to look into it<br>
&lt;fantasai> https://drafts.csswg.org/scroll-animations-1/<br>
&lt;TabAtkins> fantasai: Worth reminding that there is a SLA ED that was already adopted<br>
&lt;TabAtkins> fantasai: Our issue was just about redesigning how the declarative syntax works<br>
&lt;flackr> q+<br>
&lt;Rossen_> ack flackr<br>
&lt;fantasai> fantasai: question is, do we want to make changes going in this direction<br>
&lt;TabAtkins> flackr: Overall I think this is a nice change. There's some use-cases we shoudl consider that we might be dropping, but I'm supportive of this overall direction.<br>
&lt;TabAtkins> flackr: We should probably change the JS API to roughly match the proposed CSS timelines; view-timeline and scroll-timeline as things you con construct, but also keep the arbitrary-element selection that the JS API can allow<br>
&lt;Rossen_> ack flackr<br>
&lt;TabAtkins> fantasai: Yeah we didn't review the JS part at all; figured we'd hash this out and bring it back to JS<br>
&lt;fantasai> s/bring/then bring<br>
&lt;TabAtkins> Rossen_: Last comments or objections?<br>
&lt;TabAtkins> RESOLVED: Adopt fantasai/miriam's new direction for the declarative side of scroll-linked animations<br>
&lt;TabAtkins> RESOLVED: Add flackr as editor to scroll-animations, move Majid to Former<br>
&lt;TabAtkins> [other editors are all still fine]<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6674#issuecomment-930334244 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 29 September 2021 16:24:39 UTC