Skip to content
This repository has been archived by the owner on Jun 16, 2018. It is now read-only.

rebuild stylesheet to separate layout from animation #12

Open
Jheronymus opened this issue May 25, 2015 · 1 comment
Open

rebuild stylesheet to separate layout from animation #12

Jheronymus opened this issue May 25, 2015 · 1 comment

Comments

@Jheronymus
Copy link
Member

I'm not sure to what extend this is possible, but it would be great to give users and designers a bit more freedom by separating layout and animation into different classes.

That way you should be able to add a class like 'animate_push_in' and 'animate_fade_out' to the element for easier animating.

@rikkertkoppes
Copy link
Member

I bit like this?: https://daneden.github.io/animate.css/

Also, the way angular solves this is worth a thought (https://docs.angularjs.org/guide/animations). We could basically automatically add and remove classes when a status changes:

  • when the "hide" button is pressed add class animate-hide
  • after the animation, remove class animate-hide

Angular also does some magic to figure out how long the animations take and when to remove the animate class. We may be able to do it a bit simpler and just remove after 5 sec or so. (should be longer than most animations, but shorter than the expected status change interval)

these classes can maybe canonically bound to the exposed api functions.

Basically, I can see two approaches

Classname denotes type of animation

This would simplify defining a bunch of classes, like in animate.css to create different styles of animation. We should maybe then use a configuration mechanism to couple the animation to events.

Next question would be whether we need to define animations per theme, or come up with a system that is independent of a theme

Classname denotes action

Like the angular example above. If we have a library with @keyframes animations, the configuration part is declaring the canonical class names (animation-show etc) and adding references to the animation names.

I like the second approach better, what are your thoughts?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants