Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
[css-animations] Clarify properties that are not allowed in @keyframes rule #2736
What I wanted in the spec is an equivalent section with "Processing a keyframes argument" in the web animation spec.
In the sentence:
I'm not sure what "accepts" means here (are such properties ignored silently? Do they generate errors? Are they available in the CSSOM?). However, I suspect we want to do what Gecko does here and parse such properties, expose them in the CSSOM, but simply not animate them. i.e. this is Issue 1 from the spec:
That would allow, for example, polyfilling an animation that includes the
We should also get all those animation types documented in CSS V&U. Perhaps that's something I can follow up on in July.
The current spec text in css-animations is very explicit, but probably isn't consistent with the current intention:
The transition properties aren't defined in css-animations, so they wouldn't be covered by that rule.
It should probably be rewritten to focus on whether or not the property is animatable, as defined in CSS Transitions (factoring in the current definition of "animatable" as separate from "interpolate-able").
Regardless, Brian has a good point about CSSOM: for properties that aren't animatable/allowed in keyframes, should they be dropped by the parser, or should they be accepted by the parser but ignored as far as applying the animation?
The same section later says:
Which seems to imply there is a difference between "ignored" declarations and "invalid and ignored" declarations.
This is the part that needs to happen in V&U. That is, the long term plan is that every property has an "Animation type" field (currently still called "Animatable" in some specs) and the definition of that type links either to a common definition in V&U or to a local definition in that spec. The following properties, however, will have "Animation type: Not animatable":
referenced this issue
Jun 6, 2018
Can I help? I want to fix #2737, and am willing to help figuring out its dependencies. What do you think needs to be refactored about V&U? And by the way, wouldn't sort of thing work better in css-cascade instead?
I would love your help!
Originally @tabatkins suggested the definition of animation types could go in V&U and it certainly made sense to me at the time. I'm not sure I understand why css-cascade would be better.
The rough idea is that there are up to three procedures that make up a type's animation behavior:
These procedures are defined in the abstract in Web Animations: procedures for animating properties.
For most types, addition is identical to accumulation and in most cases spec authors should not have to concern themselves with the difference between these two procedures. Web Animations tries to define things such that accumulation defaults to being equivalent to addition and we should probably preserve that however we link these definitions together.
Likewise, addition doesn't make sense for many types so we should also have a sensible default for that so that in many cases all you need to define is interpolation (like Web Animations attempts to do).
Currently the definition of animation types is mostly found in CSS Transitions. The proposal is to take that and move it to V&U (or wherever is most appropriate) since it is used by CSS Transitions, CSS Animations, and Web Animations.
Web Animations also has a few definitions of animation types for a limited set of types. Most of that spec text, however, should just be dropped once we have something equivalent in V&U. I'm happy to help with that part.
When I tried to spec this in V&U I wasn't sure how to arrange it. For example, take the
In fact, it seemed like a lot of the sections would get a lot longer and I wasn't sure if it was better to create a new section for animation types and risk having them get out of sync or interrupt the definitions of these types with all this talk about animation.