- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Mon, 20 Mar 2023 14:41:04 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-animations-2][scroll-animations-1] Keyframe ordering and ordering requirements`, and agreed to the following: * `RESOLVED: Collapse keyframes with same specified offset to the earlier one, then pull percentage-only keyframes to the front and sort them` <details><summary>The full IRC log of that discussion</summary> <fantasai> s/Topic/Subtopic/<br> <fantasai> s/Topic/Subtopic/<br> <emilio> flackr: css-animations defines that there's a sorting of keyframes by offset<br> <fantasai> i/scribenick/Topic: Scroll Animations/<br> <emilio> ... timeline-range keyframes have effectively dynamic offsets<br> <emilio> ... further, web-animations requires keyframes to be sorted and throws if not<br> <emilio> ... proposal is for css animations if you look at keyframes you'll sort by the computed offset which means that the keyframe order can switch depending on layout offsets<br> <emilio> ... we shouldn't merge keyframes with same computed offset but different specified offsets<br> <emilio> ... there's an exception already for different composite modes and easing<br> <emilio> ... if you have a not-computed offset<br> <emilio> ... I'm proposing we just keep them in the stable sort order relative to the other keyframes around them<br> <emilio> ... so basically you do a stable sort but keyframes with no offset are not comparable<br> <emilio> q+<br> <emilio> flackr: there'd be no changes for web animations, what you pass is what you get, and we'd relax the requirement to specify them in order<br> <emilio> ... so that only fixed offsets need to be sorted<br> <Rossen_> ack fantasai<br> <emilio> fantasai: so you're proposing that whatever keyframes get passed in and if they don't have a resolvable offset do they get dropped?<br> <emilio> flackr: they're dropped from the animation but getKeyframes would still return them as described above<br> <Rossen_> ack emilio<br> <fantasai> emilio: Does this mean that calling getKeyframes now needs to do a layout update, rather than just styling?<br> <fantasai> flackr: yes, if the animation has range-based keyframes, it needs a layout update...<br> <fantasai> flackr: I believe that at least Chrome didn't differentiate between style and layout in this case<br> <fantasai> emilio: I'm pretty sure we do<br> <fantasai> emilio: Chrome doesn't have such a strong difference between update style vs layout<br> <fantasai> emilio: but we do have that difference<br> <fantasai> emilio: although container queries make that tricky<br> <emilio> fantasai: would it make sense not to do the layout-based sort?<br> <emilio> fantasai: so percentage-based keyframes are sorted but the others remain stable<br> <fantasai> emilio: I think that might be slightly preferable<br> <fantasai> emilio: the less we need to update for DOM APIs the better<br> <ydaniv> q+<br> <chris> regrets+ lea<br> <emilio> fantasai: why are we sorting these at all? Can we have the API not sort them?<br> <emilio> flackr: for WebAnimations it asserts that they're sorted, which we need to relax<br> <emilio> ... for CSS animations it's spec'd that we'd sort the keyframes by the percentage specified<br> <emilio> ... this is observable and it'd be hard to know whether it's compatible to change that<br> <emilio> fantasai: what if we zero out the dynamic offsets when sorting so that we have a canonical order?<br> <emilio> ... if there's a percentage offset we sort by that but for range we treat as zero<br> <emilio> flackr: I feel like if we treat range separate we can just leave them in the specified order<br> <emilio> ... I think the main reason keyframes are sorted by percent is for merging and we don't want to merge these<br> <emilio> YehonatanDaniv: the only case offsets could change dependent on layout is changing ?? to cover<br> <emilio> ... I think that's the only case which is kind of minor<br> <emilio> flackr: anything other than cover computes its offset based on the timeline<br> <Rossen_> ack ydaniv<br> <fantasai> flackr: cover is the only case where the % specified is equivalent to the percentage in the timeline<br> <fantasai> flackr: otherwise the % is dependent on layout<br> <fantasai> flackr: e.g. range of 100% is dependent on the element size<br> <fantasai> YehonatanDaniv: larger or smaller than viewport?<br> <fantasai> flackr: any change in the element's height changes what 'enter 100%' results in<br> <fantasai> YehonatanDaniv: but that doesn't change the order of keyframes<br> <fantasai> flackr: ah, yes. If you have keyframes of multiple ranges specified<br> <fantasai> YehonatanDaniv: I think if the only edge case is missing one of the 1st three with cover, then reasonable not to update the order of the keyframes according to layout changes<br> <bramus> q+<br> <fantasai> YehonatanDaniv: we have duration and currentTime update, but order of keyframes doesn't need to change in most cases<br> <fantasai> flackr: but the question is what should spec say about order of keyframes?<br> <fantasai> YehonatanDaniv: I think everything else still holds, we have logical order of entry/contain/exit, and then entry-crossing/exit-crossing<br> <fantasai> flackr: there's overlap among those phases, and cover covers all of them<br> <fantasai> YehonatanDaniv: cover is the special case<br> <fantasai> flackr: entry-crossing and exit-crossing are also special<br> <fantasai> flackr: one possibility is we could have sort by range name and then percentage<br> <fantasai> flackr: that defines a DOM ordering<br> <fantasai> flackr: or we could leave them as specified in the CSS<br> <fantasai> flackr: which is consistent with what we do when keyframes have different easings or composit modes<br> <fantasai> flackr: they stay in their specified order<br> <fantasai> flackr: so in the absence of any reason to sort we use the specified order<br> <fantasai> YehonatanDaniv: ok, by range name and offset, but need to clarify regarding special cases<br> <fantasai> flackr: the other reason that sorting matters is it affects which keyframe values are active for a particular range<br> <fantasai> flackr: if 2 keyframes compute to 20%, when you're after 20%, which keyframe's values are you getting?<br> <fantasai> flackr: if one says 'bg: green' other is 'bg: blue', need to know which is later to know what color to get<br> <fantasai> flackr: my proposal is in all complex cases we use specified order<br> <fantasai> flackr: that removes layout order, and produces a well-defined animation<br> <fantasai> YehonatanDaniv: consistent also with [missed]<br> <fantasai> flackr: consistent with what we do with easing and composit mode<br> <fantasai> bramus: Also wanted to point out order can change if size of scroller changes<br> <emilio> bramus: wanted to point out that order of the keyframes can change if size of scroller changes<br> <fantasai> bramus: e.g. 'enter 100%' and exit animation starts when scroller becomes too small<br> <Rossen_> ack bramus<br> <fantasai> bramus: authors can predict what happens, so I'm in favor of this proposal<br> <emilio> fantasai: I wanted to ask what the proposal is? Don't sort other than the percentage based ones? If two keyframes have the same offset even in different phases we don't merge them?<br> <emilio> flackr: we won't merge if they have the same computed offset<br> <emilio> fantasai: even if they have the same specified offset?<br> <emilio> flackr: we can merge then, it's not complex and is consistent with the expectations for other animations<br> <emilio> fantasai: I think we could propose that keyframes with the same specified offset are merged<br> <emilio> fantasai: what happens if there's interleaved keyframes and ranged?<br> <emilio> flackr: the index of the specified keyframe is the secondary sort order<br> <emilio> fantasai: so say I have 0%, entry, 0%, entry, 20%, entry, 50%<br> <Rossen_> q?<br> <fantasai> 20%, entry 50%, 0%, entry 0%, entry 6em<br> <Rossen_> ack fantasai<br> <emilio> flackr: I was wondering if we could be really naive and use stable sort where values are equal if any value has ranges<br> <emilio> ... so only the 0% will move before the 20%<br> <emilio> flackr: for applying the animation later we need to sort by computed offset<br> <emilio> fantasai: right but you want percentages in order, but ranges don't matter<br> <emilio> ... so do you ?? or move all the percentages first?<br> <emilio> flackr: I think percentages at the beginning would be simplest<br> <emilio> fantasai: I think otherwise you need to chop up the list and sort the fragments<br> <Rossen_> 0%, 20%, entry 50%, entry 0%, entry 6em<br> <fantasai> Percentages at the beginning option: 0%, 20%, entry 50%, entry 0%, entry 6em<br> <fantasai> Segmented list option: 0%, entry 0%, entry 6em, 20%, entry 50%<br> <emilio> flackr: my concern with the segmented option is that percentages are not guaranteed to be sorted among them<br> <emilio> fantasai: I'm not sure it makes sense, I'm saying "I'm a complex list so my order is whatever"<br> <emilio> flackr: I'm not sure it makes sense to do that<br> <emilio> q+<br> <fantasai> s/whatever/that of the most recently-specified raw percent keyframe/<br> <fantasai> emilio: I was going to say that seems more simple and intuitive to me<br> <Rossen_> ack emilio<br> <fantasai> emilio: put percentages at the beginning, then sort the rest<br> <fantasai> PROPOSAL: Collapse keyframes with same specified offset to the earlier one, then pull percentage-only keyframes to the front and sort them<br> <emilio> RESOLVED: Collapse keyframes with same specified offset to the earlier one, then pull percentage-only keyframes to the front and sort them<br> <fantasai> Rossen_: OK, we're resolved. As you get more experience with this, let us know if it works<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8507#issuecomment-1476358844 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 20 March 2023 14:41:06 UTC