[web-animations-2] [scroll-animations] Web Animations Level 2 is labeled as "Not Ready For Implementation" and yet is required to implement Scroll-driven Animations

[graouts]

I've been working on implementing Scroll-driven Animations in WebKit and am concerned about the state of the relevant specs as we're getting closer to determining whether to enable this feature in an upcoming Safari release. My biggest overall concern is that the Web Animations Level 2 specification contains several incremental updates over Web Animations Level 1 which are requirements for the implementation of Scroll-driven Animations, and yet Web Animations Level 2 has a prominent "Not Ready For Implementation" label.

I think this is due to Web Animations Level 2 being the only spec where advancements over Web Animations Level 1 live, which includes both incremental updates over Level 1 for many existing procedures as well as substantial new features such as the Grouping and Synchronization features.

I believe those new features are the parts that warrant the "Not Ready For Implementation" label. To my knowledge, there are no active efforts to implement those, whereas the incremental updates have been implemented and shipped by Chrome to support Scroll-driven Animations and are being actively implemented by the WebKit and Firefox teams.

I'm not sure what the best way forward is, but I think it is important for updates to Web Animations Level 1 required for the implementation of Scroll-driven Animations to be contained in a spec that has no "Not Ready For Implementation" label. Perhaps there should be a Web Animations Level 3 spec for the new features, leaving Web Animations Level 2 as a group of incremental updates to support Scroll-driven Animations? Or perhaps those incremental updates should be made in Web Animations Level 1 since that spec is still a Working Draft?

I'm sure there are other options I don't envision and these should be discussed quickly if we want to broaden the number of implementations for Scroll-driven Animations.

[graouts]

Cc @flackr, @kevers-google, @andruud and @bramus.

[bramus]

I think it is important for updates to Web Animations Level 1 required for the implementation of Scroll-driven Animations to be contained in a spec that has no "Not Ready For Implementation" label.

+1 on this concern.

For completeness: there are also two appendices in the scroll-animations-1 spec that are marked for relocation to the CSS-ANIMATIONS-2 and/or WEB-ANIMATIONS-2 specs.

• https://drafts.csswg.org/scroll-animations-1/#timeline-ranges
• https://drafts.csswg.org/scroll-animations-1/#timeline-name-scope

[birtles]

Slightly tangential, but I really want to get level 1 to CR in the coming months. To that end, I'm employing an engineer part time to work on the issues blocking that, the biggest being #5394. I really hope WebKit and Chrome are able to implement that change once it's specced.

Once the major issues in level 1 are settled, we can move stop level 2 from being a delta spec.

For now, though, would marking level 2 as ready for implementation and annotating the group and custom effect features as "not ready for implementation" work?

[ydaniv]

I have a big WIP PR on level 2 adding AnimationTrigger. I'd appreciate landing it first if possible without any major conflicts.
With that in mind, I don't know the plans that others have for the Group and Custom parts, but perhaps it would make sense to split the other deltas plus AnimationTrigger as level 2, and the rest as level 3?

[flackr]

For now, though, would marking level 2 as ready for implementation and annotating the group and custom effect features as "not ready for implementation" work?

I think this would be good. We could move those features to an appendix which I've seen other specs use as a holding place for features which haven't reached the same level of readiness as the rest in the specification.

[graouts]

For now, though, would marking level 2 as ready for implementation and annotating the group and custom effect features as "not ready for implementation" work?

I think this would be good. We could move those features to an appendix which I've seen other specs use as a holding place for features which haven't reached the same level of readiness as the rest in the specification.

That sounds good to me.

[birtles]

On further thought, is there any reason to keep group effects and custom effects as "not ready for implementation"? I think those features are only ever go to stabilize through implementation experience?

[flackr]

On further thought, is there any reason to keep group effects and custom effects as "not ready for implementation"? I think those features are only ever go to stabilize through implementation experience?

Right, I agree they're probably as ready as they will be for trying an implementation, though the process of doing so is likely to require further changes. Whereas, we have implementation experience with the finite timeline and CSSNumberish modifications.

Though I'm not opposed to declaring that both are ready for implementation, I just suspect that at a later stage we may need to split them if we don't get implementation experience.

[birtles]

Though I'm not opposed to declaring that both are ready for implementation, I just suspect that at a later stage we may need to split them if we don't get implementation experience.

Yes, I can see that being likely. I think it's fine to mark the whole spec as ready for implementation and later defer features to level 3 if they don't get implemented by the time level 2 is stabilised (which won't happen until we finally stabilise level 1).

[ydaniv]

Just raising one concern, before marking GroupEffect as ready, I'd appreciate considering the following issues:

• [css-animations-2] Declarative syntax for GroupEffects #9554
• [web-animations-2] Propose a new timing option align to replace SequenceEffect #9557
• [css-animations-2][web-animations-2] Staggering children of effects inside GroupEffect #9561

Would be nice to discuss those before something is shipped.

[css-meeting-bot]

The CSS Working Group just discussed [web-animations-2] [scroll-animations] Web Animations Level 2 is labeled as "Not Ready For Implementation" and yet is required to implement Scroll-driven Animations, and agreed to the following:

• RESOLVED: remove the global warning on WA2, but put back warnings on subsections that still need work, with editor's discretion
• RESOLVED: Publish updated WD

The full IRC log of that discussion

<emilio> smfr: scroll-driven animations (shipped in Chrome, in progress in WebKit) depend on incomplete parts of WebAnimations 2
<emilio> ... so I think we need to split it up
<emilio> ... that contains the pieces that are needed for scroll-driven animations at least
<emilio> bramus: the spec has a giant "not ready for implementation" warning
<emilio> q+
<flackr> q+
<emilio> smfr: a bit sad chrome shipped without the specs finished
<astearns> ack fantasai
<ydaniv> q+
<bramus> scribe+
<bramus> emilio: which parts are needed for sda?
<bramus> … timelines i guess?
<bramus> ydaniv: ranges
<astearns> ack emilio
<astearns> ack flackr
<emilio> flackr: On the issue we discussed a bunch of this and the parts that are used for scroll animations are fine
<emilio> ... we could move them to WA1 but other of the bits like grouping and custom effects don't have implementations
<emilio> ... options...
<emilio> ... move unimplemented things to an appendix
<emilio> ... birtles wanted to keep grouping effects at least
<emilio> ... spec is good but no css syntax tho
<astearns> ack ydaniv
<emilio> ... preference would be to move non-implemented bits into an appendix and bring them back once we have impl experience
<emilio> ydaniv: replying to smfr, just a technicallity
<emilio> ... scroll animations have their own spec but the web animations bits are good to implement
<emilio> ... in that issue I put a few issues that I'd like discussion on
<emilio> ... before we remove the not ready for implementation bit
<emilio> q+
<astearns> ack fantasai
<bramus> https://github.com//issues/11466#issuecomment-2625295147
<emilio> fantasai: a feature goes through different phases
<emilio> ... design, working out details before shipping
<emilio> ... I think group effects makes sense to split out
<emilio> ... this spec is CR level for ranges
<emilio> ... so we should recognize this
<emilio> ... maybe group effects are a good idea
<astearns> q+
<emilio> ... but we should split them up
<astearns> ack emilio
<bramus> emilio: could another alternative be to move the mature parts of web animations 2 into 1?
<bramus> … rather than splitting the spec into two parts
<bramus> … in general seems fine to mark bits that are stable-ish stable
<astearns> ack astearns
<emilio> astearns: alternative change... leave everything in place and take the sections and say "these are good"
<emilio> ... to get past this
<emilio> ... not sure we need to split drafts for a subset of the draft to fix this
<bramus> q+
<emilio> ... might be able to mark things as ready despite the maturity of the other parts of the draft
<astearns> ack bramus
<ChrisL> q+
<emilio> bramus: not sure how that'd go but would it be as easy to put warnings on the unstable parts?
<emilio> astearns: was thinking of keeping the warning on the draft entirely and list the sections that are further along
<emilio> bramus: could an alternative be removing the spec and add warnings to the unstable sections?
<emilio> ChrisL: that's better
<emilio> ack ChrisL
<emilio> ChrisL: if you have a warning in your entire spec folks won't look at it
<emilio> fantasai: it's a diff spec so pulling stuff out is not hard probably
<emilio> ... some of the unstable parts might not be easy to identify tho, might be better integrated with the text
<emilio> astearns: so proposal would be to remove the spec warning and add it to the unstable sections
<emilio> ... even tho that's a bit more difficult
<emilio> fantasai: I think we should resolve to mark the separation clear
<emilio> q+
<astearns> ack emilio
<emilio> ... at editor discretion, removing the whole spec warning
<bramus> emilio: as an implementer, diff specs are annoying
<bramus> … if we are surea bout the stability prefernces would be to merge into level 1
<bramus> … would there be any reason not to do that?
<flackr> q+
<bramus> … i understand to remove the warning and x as a stop gap
<bramus> … but longer term, do we want to put it all in 1 spec instead of a diffspec?
<fantasai> fantasai: in the long term, diff specs should be undiffed
<astearns> ack flackr
<emilio> flackr: responding to emilio
<emilio> ... there are some details in the scattered diffs that incorporate some of the changes needed for grouping of effects
<emilio> ... it'd be trivial to say that grouping and sequencing could be removed
<emilio> ... wouldn't be trivial to apply the diff with those bits removed right now
<bramus> emilio: sounds good
<emilio> flackr: maybe we rework those bits into their own sections
<bramus> s/emilio: sounds good//
<emilio> ... but it's a bit more work
<emilio> emilio: sounds fine to flag stuff as a stopgap
<TabAtkins> flackr: also i believe there was still some stabiliation work to be done on WA1 that I think Brian was planning on finishing
<TabAtkins> flackr: so doing the merge fo the diff before that would introduce additinoal churn
<TabAtkins> astearns: proposed resolution: remove the global warning on WA2, but put back warnings on subsections that still need work, with editor's discretion
<emilio> +1
<TabAtkins> fantasai: and then publish an updated WD
<TabAtkins> astearns: yes
<TabAtkins> astearns: objections?
<TabAtkins> RESOLVED: remove the global warning on WA2, but put back warnings on subsections that still need work, with editor's discretion
<fantasai> RESOLVED: Publish updated WD