- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 12 Apr 2023 16:18:41 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[web-animations-2] Prefer phase based start / end delays over converting time based delays`, and agreed to the following: * `RESOLVED: Times in a non-time-based timeline are converted to their relative %s.` * `RESOLVED: Once group effects are added, also add %-based delays/durations.` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> flackr: We defined a Web Anim 2 feature for converting time-based to run on non time-based timelines<br> <TabAtkins> flackr: So they'd "just work", continuing to use %s<br> <TabAtkins> flackr: Another idea came up to simplify, treating time-based durations and delays as their initial value (as if they're invalid)<br> <TabAtkins> flackr: This works for simple cases, but concern if you have a time-based group or sequence effect, the delays between effects are very important for relative timing<br> <TabAtkins> flackr: You couldn't take one of those and switch it to a different timeline if we didn't preserve those delays<br> <TabAtkins> flackr: So two options, one is continue to convert all times to relative %s when running a time anim on a non-time timeline<br> <TabAtkins> flackr: This ensures relative timing between effects stays<br> <TabAtkins> flackr: Other is we use initial values, but allow specifying %-based durations/delays, which let you define the relation of different effects in a non-time-based way<br> <TabAtkins> flackr: I think first is simpler, and what we already agreed on, but wanted to confirm.<br> <TabAtkins> TabAtkins: [missed]<br> <emeyer> TabAtkins: Locking ourselves into non-time-based is a weird syntax; if that’s not the case, fine<br> <emeyer> s/is/with/<br> <TabAtkins> flackr: We'll still want to define a % delay for these non-time things, but this wouldn't be required for existing ones<br> <TabAtkins> flackr: Something raised is it should be possible to take a time-based anim and switch it to a non-time timeline, and have it pick up where it left off<br> <TabAtkins> flackr: Which #1 will do<br> <TabAtkins> fantasai: So is proposed resolution that we'll autoconvert time-based delays, and *also* add % delays?<br> <TabAtkins> flackr: that sounds good to me<br> <TabAtkins> flackr: Group and sequence effects aren't implemented currently, so I think we should add % delays at some point before/as we implement group/sequences.<br> <TabAtkins> fantasai: If the main thing you'r eusing the delay for is to create overlapping effects, in a time-based system are you able to specify you anims in a way that's easy and comfortable, given you're combining %s and times<br> <TabAtkins> fantasai: Feels like that can be a little awkward, two different units<br> <TabAtkins> flackr: I think the way author would use %s is they'd define a duration for the overall group or sequence, adn the effects within would be %-based<br> <TabAtkins> flackr: They could mix-and-match but it would get confusing.<br> <TabAtkins> fantasai: Tangential, do we want to introduce frs as a keyframe offset mechanism? Then you don't have to reshuffle all your %s if you insert some frames.<br> <TabAtkins> (probably good to bring up as a separate issue)<br> <TabAtkins> astearns: Should raise separately<br> <TabAtkins> fantasai: Will do, just wanted to think aobut it in context<br> <TabAtkins> astearns: Othe ropinions? Rob, can you summarize resolution?<br> <TabAtkins> flackr: When running an animation with defined times in a non-time-based timeline, we convert those times to their relative %s of the overall effect.<br> <TabAtkins> +1<br> <TabAtkins> astearns: Concerns? Objectinos?<br> <TabAtkins> RESOLVED: Times in a non-time-based timeline are converted to their relative %s.<br> <TabAtkins> flackr: Should we also resolve to add %-based delays?<br> <TabAtkins> fantasai: If that's only needed for groups/seqs, we should add it when we do those.<br> <fantasai> fantasai: but we should resolve now<br> <TabAtkins> astearns: So proposed resolution is to add % delays once we add group effects?<br> <TabAtkins> (clearly just use `-duration: 100s`, then 5s == 5%)<br> <fantasai> fantasai: because having time-based delays that get auto-converted to lengths be the only way to sequence group affects on a scroll animation is just too weird<br> <TabAtkins> flackr: I'm good with that proposed res<br> <TabAtkins> astearns: Objections?<br> <TabAtkins> RESOLVED: Once group effects are added, also add %-based delays/durations.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7749#issuecomment-1505563335 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 12 April 2023 16:18:43 UTC