Why animatable CSS properties reference was removed?

[Vallek]

MDN URL

https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_animated_properties

What specific section or headline is this issue about?

Animatable CSS properties reference

What information was incorrect, unhelpful, or incomplete?

This page contained full list (reference) of animatable CSS properties. Which was obviously helpful. It's gone now.

What did you expect to see?

Full list of animatable CSS properties

Do you have any supporting links, references, or citations?

You can still see it in french version for example. And in archive.

Do you have anything more you want to share?

Please bring it back.

MDN metadata

Page report details

• Folder: en-us/web/css/css_animated_properties
• MDN URL: https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_animated_properties
• GitHub URL: https://github.com/mdn/content/blob/main/files/en-us/web/css/css_animated_properties/index.md
• Last commit: c9cc38c
• Document last modified: 2023-05-18T13:31:57.000Z

[yarusome]

I made #26364 and the reasons for the revamp are:

1. The Web Animations spec explicitly mentions that:

   Unless otherwise specified, all CSS properties are animatable.

   Thus exceptions are far less than the normal ones. This means even if the catalog were to be kept, it would make more sense to document the exceptions instead.

2. Given that there're more and more new properties invented constantly, it's quite difficult to maintain the accuracy of the list.

3. The original list only differentiated animatable and non-animatable properties, without any useful descriptions on each animation type.

4. The exact animation type of each property is already listed in its "Formal definition" section.

If you find the list useful, could you elaborate why there's a need in the first place to see the complete list of animatable properties?

[Vallek]

Thanks for a quick answer!

This makes sense. Then I think there at least should be the list of exceptions.

The list was useful for a quick check if I'm trying to animate something that's not animatable) I know you can check property page, but this could be more convenient for multiple properties. And also for education (i gave this link to my students).

I also don't know how MDN is build but maybe you can just pick up properties with right animation type and put them on this page?

[Josh-Cena]

I also don't know how MDN is build but maybe you can just pick up properties with right animation type and put them on this page?

We used to do that, but any kind of programmatic text generation requires a macro and we are generally moving away from macros. I personally don't see how we can achieve this without macros, so we are just refactoring our content to get around the limitation.

@yarusome Do you have plans on addressing this? The point about educational value seems reasonable. A list of exceptions should work.

[yarusome]

@Josh-Cena I can make a PR to list non-animatable properties on that page, but it somewhat contradicts one of the original goals, i.e. eliminate the need to maintain a list all along. 🤔

Other question before opening a PR:

• I'd like to only list specced properties since non-specced ones are hard to verify and update their statuses.
• @Vallek Do you want to check for non-animatable properties or discretely-animatable ones? The former group only contains a few properties such as animation-* and transition-*, which can be mentioned as a note on that page instead. (I want to make sure if we're talking about the same concept.)

[Vallek]

@Josh-Cena

we are generally moving away from macros

Can I ask why? Just out of curiosity)

@yarusome

Do you want to check for non-animatable properties or discretely-animatable ones?

You know thinking about this now: my personal case was to check if property/properties (it could be any) is animatable. I just preferred one page list. So I'm not even sure if I would use non-animatable properties list. I guess it will be easier now to just check on each property page instead.

But that's just me. I'm not sure what would be better universal solution (outside of initial one page).

[Josh-Cena]

Can I ask why? Just out of curiosity)

I dunno; I wasn't the one making the decision. My guesses are:

1. Some macros' implementations are very complicated and negatively impact build performance.
2. Macros aren't supported by other Markdown renderers and don't work for every contributing workflow (e.g. if you are editing through the GitHub interface).
3. Macros are maintained with the platform (Yari) instead of the content, so updates to the content may require another commit to update the macro.

I'll leave it to you folks to decide what we should do. My personal take is that an overview of some sort is valuable but not necessary, and if @Vallek doesn't feel strongly any more, we can close it until someone else asks for it.

[Vallek]

My personal take is that an overview of some sort is valuable but not necessary

Yeah I think I agree. Would be nice to have it, but as longs as you can just check each page it's not crucial.

[Josh-Cena]

Sure, let's close this for now.

[yarusome]

@Vallek FWIW, latest statuses can be extracted from @webref/css.

[Vallek]

I'll try to put a page together with a list from api and post link here later.

[Vallek]

Ok, so I made a page with lists of animatable and not animatable CSS properties. Here it is: vallek.github.io/animatable-css/

It updates once in a day and generates static html so minimum strain on api or client)

@yarusome Thanks for the api link!