Hi @flackr and welcome to web-features.

I've got some background on this description and then a question for you.

This feature is described in terms of animate() because we're aligning to how caniuse represents web animations as a high-level feature. Although it's possible to work with animations in other ways, caniuse doesn't condition support on those ways, some of which came later (e.g., getAnimations()). We can't (significantly) change this description without breaking our link to the caniuse feature (that is to say, we can't continue to claim to be talking about the same feature as caniuse).

Right now, we're working on an initial pass of the platform, to capture everything (albeit rather imperfectly). We have a number of issues open to better address what we've been calling "later additions" and this appears to be one of them. Those other methods are in fact part of the feature, but they don't contribute to the overall headline status. See https://github.com/web-platform-dx/web-features/blob/main/features/web-animations.yml.dist for details.

Given this background, does the description make some more sense? Would it be helpful to have distinct features for some of the later additions? Or is it still the case that your model of "web animations" must have Animate() and getAnimations() as well as animate()?

Hi @flackr and welcome to web-features.

I've got some background on this description and then a question for you.

This feature is described in terms of animate() because we're aligning to how caniuse represents web animations as a high-level feature.

The definition on the linked page supports the modification here, in particular it says:

• Lets you create animations that are run in the browser

  The same animations that run in the browser are also be created by using the Animation constructor directly.

• as well as inspect and manipulate animations created through declarative means like CSS.

  This is only supported through the getAnimations() API.

Although it's possible to work with animations in other ways, caniuse doesn't condition support on those ways, some of which came later (e.g., getAnimations()). We can't (significantly) change this description without breaking our link to the caniuse feature (that is to say, we can't continue to claim to be talking about the same feature as caniuse).

I believe it is the very same feature. Browser versions that only support Element.animate are listed as partial support on caniuse.

Right now, we're working on an initial pass of the platform, to capture everything (albeit rather imperfectly). We have a number of issues open to better address what we've been calling "later additions" and this appears to be one of them. Those other methods are in fact part of the feature, but they don't contribute to the overall headline status. See https://github.com/web-platform-dx/web-features/blob/main/features/web-animations.yml.dist for details.

I think this is important in establishing what counts as use and tests of the described feature.

Given this background, does the description make some more sense? Would it be helpful to have distinct features for some of the later additions? Or is it still the case that your model of "web animations" must have Animate() and getAnimations() as well as animate()?

I think it is still the case that it must have new Animation() and getAnimations() as well.

Thanks for the update, @flackr. I think I've misunderstood some pieces of this, so I'm going to take a closer look at the data and see what I can do here with the feature pinning, to unblock changing the description.

I think it is still the case that it must have new Animation() and getAnimations() as well.

I don't agree with this. I think that the Web Animations API is very useful even if you don't have getAnimations(). Being able to programmatically create and run an animation, either using the Animations constructor, or the animate() method is already enough to warrant its own feature on the repo (which is what we did)

That being said, caniuse does bundle them together as one feature, as @flackr said and, indeed, browsers that don't support getAnimations are marked as partially supportted:

So we can go 2 ways:

• Either care about strictly mapping to caniuse and we add the various getAnimations() methods from BCD to our web-animations feature. This would push the baseline date ahead quite a bit, but the feature would remain baseline high.
• Or we create a new feature just for the later addition of getAnimations().

I would personally go for the former because all of this is baseline high already.
If we lived a few years in the past, when the implementation of WAAPI was happening, it would make a lot of sense to create many smaller features. The WAAPI took a really long time to come together and had many different parts to it (Mozilla even had a whole dedicated page to track progress over multiple releases). But time has passed, and the API is now mostly supported.