Re: [csswg-drafts] [scroll-animations-1] Unifying ScrollTimeline and ViewTimeline (#7462)

The CSS Working Group just discussed `unifying scrolltimeline and viewtimeline`, and agreed to the following:

* `RESOLVED: close no change`

<details><summary>The full IRC log of that discussion</summary>
&lt;TabAtkins> Topic: unifying scrolltimeline and viewtimeline<br>
&lt;TabAtkins> github:<br>
&lt;TabAtkins> github: https://github.com/w3c/csswg-drafts/issues/7462<br>
&lt;TabAtkins> bramus: given the syntax we just agreed on (also listed in the issue0<br>
&lt;bramus> @keyframes fade-in-rotate-fade-out {<br>
&lt;bramus>   enter 0% { opacity: 0; }<br>
&lt;bramus>   enter 100% { opacity: 1; }<br>
&lt;bramus>   contain 100% { rotate: 1turn; }<br>
&lt;bramus>   exit 0% { opacity: 1; }<br>
&lt;bramus>   exit 100% { opacity: 0; }<br>
&lt;bramus> }<br>
&lt;TabAtkins> )<br>
&lt;TabAtkins> bramus: i was wondering if we could automatically derive the meaning - what is being targeted from these keyframes<br>
&lt;flackr> q+<br>
&lt;TabAtkins> bramus: right now we have scroll-timeline to target scroller, view-timeline to target an element as it intersects the viewport, and separate css properties for these<br>
&lt;TabAtkins> bramus: not suggesting to merge the concepts, but maybe one set of properties that do it all and derive what's meant from the keyframes<br>
&lt;astearns> ack fantasai<br>
&lt;TabAtkins> fantasai: i dont' think this is a good idea<br>
&lt;TabAtkins> fantasai: they're diff concepts with diff properties, many different settings<br>
&lt;TabAtkins> fantasai: and an element could both establish a scroll timeline and have a veiw anmiation, etc<br>
&lt;TabAtkins> fantasai: if we tried to do some magical switching it'll be more confusing i think<br>
&lt;TabAtkins> fantasai: also switching based on wehtehr keyframes target phases isn't a good idea, maybe you want to reuse keyframes<br>
&lt;TabAtkins> fantasai: the way you use them shouldn't change the kind of timleine you're attaching to<br>
&lt;TabAtkins> bramus: i see so if you had regular parts, like from/to offsets, you could do a regular<br>
&lt;flackr> qq+<br>
&lt;TabAtkins> fantasai: the keyframes aren't meant to be targeted<br>
&lt;TabAtkins>  fantasai: meant to be a nice general way to specify progress<br>
&lt;astearns> ack florian<br>
&lt;astearns> ack flackr<br>
&lt;Zakim> flackr, you wanted to react to fantasai<br>
&lt;astearns> ack flackr<br>
&lt;TabAtkins> flackr: I don't think the switch is as fundamental as you're suggesting<br>
&lt;TabAtkins> flackr: Mos timportant distinction is the element used as subject means something different for view and scroll timeline<br>
&lt;TabAtkins> flackr: Other than that, if the defualt range is the same, they're basically the same thing, and you use phase selection to target [...]<br>
&lt;TabAtkins> flackr: so i'm good with the idea of closing this<br>
&lt;TabAtkins> flackr: just wanted to point out that it's a very minor diff between the two<br>
&lt;TabAtkins> bramus: I'm okay with closing<br>
&lt;TabAtkins> RESOLVED: close no change<br>
</details>


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


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

Received on Wednesday, 3 August 2022 15:14:20 UTC