- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 08 Dec 2022 00:43:12 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[scroll-animations-1] Bring back Scroll Offsets`. <details><summary>The full IRC log of that discussion</summary> <dael> Rossen_: This is a fairly long issue<br> <Rossen_> Initial Proposals Summary: https://github.com/w3c/csswg-drafts/issues/7575#issuecomment-1207786782 Key follow-up comments: https://github.com/w3c/csswg-drafts/issues/7575#issuecomment-1209635142 https://github.com/w3c/csswg-drafts/issues/7575#issuecomment-1253314529 Second Proposals Summary: https://github.com/w3c/csswg-drafts/issues/7575#issuecomment-1306103577 Key follow-up comments: https://github.com/w3c/csswg-drafts/issues/7575#[CUT]<br> <dael> Rossen_: You can follow initial proposals and key follow-ups from there ^<br> <dael> bramus: With the previous iteration of scroll linked animations that use scroll linked timelines and this is not in the re-write<br> <birtles> q+<br> <dael> bramus: A few suggestions, 8 Nov comment from fantasai summeries. Add a length % for naimation delay and animation duration. That way you can drive scroll linked animation over spec distance<br> <dael> Rossen_: On this side of the pond the comment is on Nov 7<br> <Rossen_> ack freereyes<br> <Rossen_> ack birtles<br> <dael> birtles: I'm not opposed to adding the different units to delay. Concern I raised is architectural. From API PoV there's 3 piecens, timeline, animations, effects. In css animation is blurred where delay is part of effect.<br> <dael> birtles: Architecturally would like effect separate so you can reuse it. That was the initial idea for the API.<br> <dael> birtles: I was a little concerned about putting in a delay because that's part of effect and makes it harder to reuse<br> <flackr> q+<br> <dael> birtles: One thought I just had there is another issue about overlap between animation range and delay. Was wondering if there's a possiblity to use animation range for this and have animation range apply to animation and animation delay apply to the effect. If we could satisfy the use case though that. Just a thought<br> <dael> bramus: That would still allow % for length but not delay<br> <Rossen_> ack flackr<br> <dael> birtles: I wondered if it applies to animation not effect architecturally more suitable<br> <dael> flackr: I think this does make use cases possible. I don't have any objection to it. Only concern is that delay does have units and it's time and they don't convert to the timelines of the effects. Have architectural breakage no matter which way we go. Not opposed, but don't think can avoid mixing units<br> <dael> birtles: I think % have slightly different case to vh units. If you can have effects defined in terms of % that's more reusable. If you have an effect that interpolates between these values over a range in the abstract and than animation maps to concrete.<br> <dael> birtles: % units and the general case of lengths I'm not opposed. nice if authors can achieve this without painting into a corner where they can't reuse the effect<br> <flackr> q+<br> <Rossen_> ack fantasai<br> <dael> fantasai: Two comments. 1 in terms of % I think % and absolute units need to be mixed. Sometimes you want absolute shift and sometimes you want relative and we combine. I don't think only % would work<br> <dael> fantasai: I think before we resolve we should jump to next issue, discuss, and then bring those decisions to this<br> <dael> flackr: You were concerned about resuability. The length values when used on a time-based timeline compute to 0 so the value are as effective as if they're in separate property. I think it's as resuable either way except you can't have a separate time-based delay<br> <birtles> q+<br> <Rossen_> ack fantasai<br> <dael> flackr: Also think delay is times so we will have to support % and times. It's hard to have a single unit world<br> <dael> birtles: With regards to fantasai point of absolute and relative I agree. We have absolute and relative times if we have %<br> <dael> birtles: Regards to reusability, on the original proposal there were 3 suggestions put forward. The third you can see the keyframes is un-effected. I guess that's an example of what I mean by reusable. It's only the second where keyframes change so maybe not important<br> <dael> bramus: In the 3rd example that uses animation timeline offsets?<br> <dael> birtles: Yes<br> <bramus> https://github.com/w3c/csswg-drafts/issues/7575#issuecomment-1207786782<br> <dael> birtles: I was saying it's possible to use a % on an effect and an absolute unit on the mapping at the animation level so you can have lengths, 90 vh on the animation, and then map to % on effect so you can combine absolute units with % without introducing diff length types<br> <Rossen_> q?<br> <flackr> q+<br> <Rossen_> ack flackr<br> <dael> flackr: In a previous breakout session and then with the group we resolved to have range-based offsets in keyframes which is laso a modification to keyframe spec that is incompat with a time-based animation<br> <dael> flackr: Based on a strong dev demand to have animation with entry and exit effect that are dynamic calc of points in scroll<br> <birtles> q+<br> <dael> flackr: Feel like that ship has sailed a bit to keep everything as %<br> <dael> flackr: I think for simple animations you will be able to reuse them. For things linked to position on length-based timeline it's not portable<br> <dael> birtles: yeah, maybe ship has sailed. Would be nice to have animation tied to mapping, but maybe too late<br> <dael> birtles: Other thing is was thinking with this use case we could realize without going further. But maybe say that's how things work now. Fair enough<br> <Rossen_> ack fantasai<br> <dael> fantasai: My suggestion is pause the convo, switch to next topic. I think a couple of these ideas are linked to next topic<br> <dael> Rossen_: We can do that unless everyone feels we're getting toward resolution<br> <dael> Rossen_: I see birtles moved himself along<br> <dael> birtles: If next issue is related we should do that first<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7575#issuecomment-1341810919 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 8 December 2022 00:43:13 UTC