-
Notifications
You must be signed in to change notification settings - Fork 197
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Animation Keyframes API Design [feedback welcome!] #431
Comments
It looks like all of the css animations at NRI are animating exactly one property ( |
With the current API users would be forced to provide at least 0% and 100%, which is nice i think. But atm you could use a different property at 0% and 100%. Would there be a nice way to enforce that properties you want to animate need to have 0% and 100%? |
This sounds great! Regarding the 0%/from and 100%/to, I'm not sure these are mandatory. The following is taken from the
This means that the same animation can be applied to elements with different initial styles (example here) which I can imagine being quite useful. I could also see specifying different 0% and Given these use cases, how about the following:
The issue around passing non-animatable properties seems a bit tricky without introducing the phantom type on |
Interesting! Here's another possible design based on that observation, as well as on the realization that it's actually possible to support keyframes : List ( Float, List Style ) -> Value { provides | keyframes : Supported }
animationName :
Value
{ keyframes : Supported
, none : Supported
, unset : Supported
, initial : Supported
, inherit : Supported
}
-> Style (If you called The implementation is a bit sneaky because as of the This would work by having |
When can we expect this to be merged? |
Not sure if this is still open or if you'd rather I open another bug. |
Sorry to necro-bump this but I'm trying to use two separate keyframe animations one on an infinite cycle and the other as a "show/hide" on opacity/height. Am I missing a way to do this with the current api or do I just need to drop down to Css.Animations.custom? |
I'd like to add animations to
elm-css
, which requires some API design work. CSS Tricks has the best intro I've read on the subject of CSS animations, and it also has links to MDN at the end.Here's a draft of an API to address how keyframes would work. (Let's assume the other properties exist; those don't have any more API challenges than the typical
elm-css
API, whereaskeyframes
is trickier.)The basic ideas are:
Css.keyframes
to define aKeyframes
value. The 0% and 100% (akafrom
andto
) styles are mandatory, but you can optionally specify other percentages as( Float, List Style )
tuples in between.Keyframes
value to animation-related properties likeanimationName
and the shorthandanimation
.Keyframes
value, just like how classnames are automatically generated by thecss
attribute today. So you'd never need to manually synchronize animation names.This doesn't offer a way to manually specify an animation name string if you really want to. That said, it would be possible to add a
Css.Global.keyframes : String -> Keyframes -> Snippet
to support that. (Note that without this, it would be impossible to specify two different animations which have the same transitions and styles, but different names. Is that a problem? I can't think of why it would be, but maybe there's a scenario I'm unaware of.)Concerns with this API:
keyframes
receives aList Style
, you can use things likehover
andimportant
with it, even though those aren't supported in the context of keyframes. It would be nice if usinghover
orimportant
in theseStyle
values didn't compile, but I can't think of a way to do that without introducing a phantom type variable toStyle
. That doesn't seem worth it to me. Can anyone think of alternate ways to enforce that?0%
and100%
transition steps. That seems like a good thing by default, since if you're doing something unusual where you don't want transition steps, you can always set them to be the same thing. However, this is CSS; there might conceivably be situations where specifying the same0%
and100%
is not equivalent to specifying only one of them - which the spec theoretically supports, but which I don't know why anyone would want.Thoughts?
The text was updated successfully, but these errors were encountered: