Effeckt.css: CSS library of performant transitions and animations for mobile

[paulirish]

Ever notice how small flourishes and subtle transitions dramatically increases the value of the experience you enjoy with an app or site?

Designing and developing UIs for the mobile web is tricky, but it's extremely difficult to do that while delivering something that performs at 60fps. The best opportunities to getting jank-free transitions on phones/tablets are css transition and keyframe animation based, especially tapping into hardware-accelerated transforms and opacity changes.

I'd like to work with some folks on a collection of transitions and keyframe animations. @daneden did really nice work with Animate.css but I think the web would benefit if we could take that work to the next level. There's already been fantastic experiments and demos exploring CSS-based transitions, but it's distributed all over. Here's a few pieces of excellent work

• tympanus.net/Development/ModalWindowEffects/
• tympanus.net/Development/PageTransitions/
• tympanus.net/Development/PFold/index2.html
• leaverou.github.io/animatable/
• lab.hakim.se/ladda/
• lab.hakim.se/kontext/
• lab.hakim.se/avgrund/
• lab.hakim.se/meny/

Because there are so many, I expect we could group things by role:

• button/touch effects
• state transition
• modal/notification transition
• attention attractors

  Goals

This library/framework would come with some goals:

1. It provides no UI of it's own. It's only hooks for transitions.
2. Designer-curated set of classy and reasonable effects. (no easeInBounce)
3. Establish browser support guidelines (I expect Android 2.3 would gracefully degrade)
4. CSS performance regression testing (a la bench.topcoat.io)
5. Deliver jank-free 60fps performance on target browsers/devices
6. If a particular effect cannot deliver target performance (hey blur() css filter), it cannot be included.
7. Guidelines on what to avoid when styling these affected elements (avoid expensive CSS)
8. Deliver a builder so users can pull only the CSS they need.
9. There is no hover on the mobile web, so any hover-based effects would be excluded.

   Holler

Anyone else been thinking along these lines?

ping @hakimel @leaverou @desandro @crnacura @botelho

Also, @daneden if you're up to it, maybe it's best to do this work as part of your already awesome project.

---

Action:

• If you know other transition/keyframe animation based demos/experiments that make senes to include here, comment below!
• If you're interested in helping to define the API let's hear it.
• A web-based builder is a must. A cmd-line builder isn't important for this, I'd say.

[jbeja]

Nice, i was hoping for something that gives me almost the same performance and smoothness as the greensock GSAP js animation library but in CSS. Now i am very excited for this.

[mnording]

This is truly something awesome for the mobile web. Really hope you are able to fulfill all goals! Except for doing your own framework previously, what experience would be beneficial for helping this project?

[necolas]

Deliver a builder so users can pull only the CSS they need.

I'd suggest creating small packages that aggregate transitions/animations of a particular kind, and then combining them all in a separate package. I did this with SUIT's utilities. Then you can share the modules on Bower and provide a single built asset for people who aren't using a package manager yet.

[sindresorhus]

I want this project so much! Currently everything is way too scattered and some of the best effects I've only discovered by coincidence. The mobile web truly needs this if it wants to stay competitive with native, especially with the new trend of even more organic interfaces, read iOS 7 and I'm sure the next Android.

I too feel strongly about it being modular and being available on package managers, while having a built asset for people just wanting to download a single file. I would be happy to build a CLI builder if anyone would find that useful.

[desandro]

Yeah, could be legit. If I'm following you correctly, this sounds like a library that provides a standardized API to do all the neato things you linked to.

In my experience, different effects call for different API. Transitions are simple one-way builds. Animations call for keyframes, which could have a whole host of parameters. There are transitions that involve multiple elements, like Hakim's Kontext or Meny. I might be over thinking it in my initial reaction, but I'd be wary of building a library that can cater to all these use cases.

I'm afraid I won't be able to contribute for a while, but I'll keep watching this issue.

[crnacura]

Fantastic idea! @botelho and I would be glad to contribute somehow with transitions and animations that fulfill the requirements.

[daneden]

Since Animate.css started, I've felt like it's been a halfway point. I'd love to contribute in any way to this project.

Daniel Eden

On 29 Jun 2013, at 19:35, Manoela Ilic notifications@github.com wrote:

Fantastic idea! @botelho and me would be glad to contribute somehow with transitions and animations that fulfill the requirements.

— Reply to this email directly or view it on GitHub.

[AaronLayton]

Hey @paulirish looks like a cool project, I'm up for it. Has anyone started anything already, something to contribute against, or are we going from scratch here?

You state no UI of it's own, just the hooks but then on point 6 mention about any styling we do add should be performant, I take it this is for things ONLY to make the effect work (say a modal drop shadow?)

Having each effect as a separate Bower package could be good but a prebuilt minified solution would definitely be better as I'm sure we will have common base CSS that will then be copied in in package.

...

I know the title says Effeckt.css but will there be a 'future' need to add in a bit of js for creating, duplicating elements for animation? Multi-Flip - http://www.apple.com/html5/showcase/transitions/

Another Model effect - http://tympanus.net/Tutorials/OriginalHoverEffects/index9.html (don't use hover obviously)

@desandro Maybe we just provide users with the performant defaults for a v1 release and then v2 we can add in the ability to do a deeper customization with ability to change keyframes?

[AaronLayton]

Also what fallback's are we going to... If we are supporting Android 2.3 then I guess it will be all the way back to IE7? As the above effects will need working on

[rudywaltz]

http://tympanus.net/Development/CreativeButtons/

[paulirish]

@necolas

I'd suggest creating small packages that aggregate transitions/animations of a particular kind, and then combining them all in a separate package. I did this with SUIT's utilities. Then you can share the modules on Bower and provide a single built asset

yes yes yes.

@jbeja

the same performance and smoothness as the greensock GSAP

Yes. I want to keep this completely declarative CSS. So no JS API of any kind. This plays well to browsers and performance, though it may be slightly more annoying to author. But better for users. Performance is key.

@desandro

In my experience, different effects call for different API. Transitions are simple one-way builds. Animations call for keyframes, which could have a whole host of parameters. There are transitions that involve multiple elements,

Yes, true. I want to do this without a JS API, so this stuff will have to be declared at the CSS level. Depending on how we do things, parameters could be defined in a builder or as mixin arguments. Also, there will be a bit of handholding and docs, I bet, to help people out with multi-element state changes.

@crnacura

I would be glad to contribute somehow

Awesome, you rock. seriously. :)

[paulirish]

@AaronLayton

Also what fallback's are we going to...

For browser support, I expect that at a minimum, you will need css transitions, opacity, 2d transforms, and keyframe animations. 3D transform support optional.

This mix picks up 85% of mobile users: http://onmobile.iwanttouse.com/#css-transitions,transforms2d,css-opacity,css-animation

If your browser doesn't have the above, it falls back to no transition at all.

And we may provide instruction to blacklist Android 2.3 in some cases. TBD.

[grayghostvisuals]

+1 for no UI. Fully customizable all the way! Can't wait to see what comes of this :metal:

[chriscoyier]

A builder is a good idea, but if that doesn't happen, writing these in Sass would be a decent idea so you just use a @mixin as needed - rather than load up a large set of animations some of which you may never use.

[jbeja]

+1 for Sass and no UI. Seriously i can't do any project without my variables, mixins and so on, also i don't like libraies that try to impose their design vision in my projects.

[kshmir]

I'd love to contribute on this! I'm working on a small project using isotope and the web needs more libraries like this.

[darsain]

@jbeja and how about libraries that impose their preprocessor of choice on everyone else? :)

[tsi]

+1 for sass and what @chriscoyier said, exactly what I was thinking.

[bensmithett]

:+1: for no UI and a Sass mixin library. You could still generate a plain old CSS build from the mixins, but for real world use I'd be converting these to Sass mixins anyway.

This is an awesome idea.

[jbeja]

@Darsain you cannot say that imposing an preprocessor is the same thing as imposing and pre-designed UI, is not like SASS, LESS or Stylus have so much difference in their syntax, features or setup to begin with, they are pretty much the same tool. I am just saying that, it would be nice a port for this project in SASS as some else would like one in LESS or Stylus. And to be honest if not like SASS as with the other tools is not compatible with vanilla CSS, i can import this library in my projects as an base and happily work with it in my favorite preprocessor. So in essence, what i am proposing in the context of the preprocessor is just a little whim for myself :).

[foleyatwork]

Author it in Sass and compile it to CSS if you want. It's all CSS in the end. That's a non-issue to me.

As far as things that should be added to the library:

• An off-canvas menu like the one on Squarespace.com (yes, I work there, but I still think it's pretty awesome).
• Drop-downs similar to the ones in Flat UI. That combination of a very small translate-y with a opacity change is really nice.

I don't have a full understanding of how the API should look, but here's a few thoughts:

• CSS is pretty simple. Let's encourage hacking the core of this library but also make it possible to use without ever touching the source.
• There will likely end up being a clear difference between how transitions are treated opposed to animations. Transitions require a beginning and end state that are usually different from one another. Animations sometimes don't end, and other times the end is the same as the beginning. They should be treated differently when we're naming the classes and deciding the use cases.

I'm definitely in for this project, it sounds awesome. I'm going to start thinking about what I'd want a library to do and jotting down some ideas. Can't wait to see some progress here.

[stephenway]

Sass is great, but I think where some Sass-exclusive libraries/frameworks fall short is with providing regular CSS to those who don't use preprocessors. Starting off with just a CSS based API is going to pave the way for preprocessor extensions anyways.

I believe there is a need for this project and I'd love to contribute where possible, especially an official Compass extension.

[chee]

+1 @stephenway

[kshmir]

+1 @stephenway. I think the api should be defined in pure, simple css (much easier to add classes in js, just like animate.css). But development without sass or a preprocessor is a no go, it would be too verbose and just not DRY. Plus, its harder to make a builder that way.

[mente]

Great idea! Willing to do LESS extension of it.

[i-like-robots]

There's certainly demand for this and knowledge shared about the performance of CSS animations will be valuable.

Is there going to be an argument soon about camelCasing or hyphen-separated naming or if the work of @daneden is extended I guess it's already decided?

[AaronLayton]

I think as a starting point we should extend from @daneden and get this reduced down with SASS. From there we can start to add in the other effects from the list @paulirish stated.

@daneden do you already have these in LESS/SASS form or did you hand code everything (props if you did!).

In the model examples from Codrops they have a base class of md-modal and then add on the effect class md-effect-1 triggering the show with md-show. Has anyone got any starting views on the API to be used? Animate.css just adds the effect class name "fadeInLeft" which is a lot simpler.

[chriscoyier]

Also be a little careful with the Codrops stuff Paul listed. http://tympanus.net/codrops/licensing/

You are not allowed to take our work “as-is” and sell it, redistribute it or re-publish it.

But we could ask @botelho / @crnacura - looks like they are already into the idea =)

[chriscoyier]

Here's a start... http://codepen.io/chriscoyier/pen/enAsf

I don't really care if it is built on CodePen or not, but that's an example of how each part could be built modularly and then have a single page that puts them all together.

[grayghostvisuals]

@chriscoyier That's dope. Would also be cool to have another stylesheet with these correlating classes (no styles just the class names) that authors could use to customize the UI further. Kind of like you did for Wordpress comments a bit back.

[KittyGiraudel]

Awesome project, I'd love nothing more than being part of it.

I think writing this in Sass is a good idea especially since it would allow easy customization with variables and mixins with arguments. As a drawback, I don't see everybody very comfortable with Sass, so this may be a little complicated for some people to use / take part in the project.

Maybe doing two versions is worth considering?

Anyway, I'm in if that's okay. :)

[grayghostvisuals]

@HugoGiraudel Honestly from my experience so far with Typeplate it was a chore to maintain multiple language ports. Obviously I would love to see Sass, but not hurt if it isn't and stays in Vanilla CSS. Somewhere down the line someone that uses Stylus will get upset that it isn't ported for them and vice versa with the others.

[crnacura]

@chriscoyier As I already mentioned, we'd love to contribute in any way possible and I don't see how our license stands against anything regarding this project (or any other project, our scripts are for free). That part in the license is just for people that copy & paste without credit, not really fair, I think ;)

[chriscoyier]

@crnacura Awesome! I added your modals: http://codepen.io/chriscoyier/pen/enAsf

at-everybody: should we move this to a repo? Probably be easier to work with as a group like that.

[KittyGiraudel]

at-everybody: should we move this to a repo? Probably be easier to work with as a group like that.

Sounds like a good idea.

[kahlil]

:+1: for putting it into a repo.

Sent from my iPhone

On 02.07.2013, at 21:35, Chris Coyier notifications@github.com wrote:

@crnacura Awesome! I added your modals: http://codepen.io/chriscoyier/pen/enAsf

at-everybody: should we move this to a repo? Probably be easier to work with as a group like that.

— Reply to this email directly or view it on GitHub.

[round]

Would be a pleasure to contribute in any way possible – these are the examples I've been use as go-tos for inspiration & code samples all along.

(Proof I like to mess with CSS sometimes: http://dabblet.com/user/DUQE)

[chriscoyier]

OK. I can do that in the next couple days. There will be a bunch of stuff we'll need to decide on and then standardize.

• Class name styles. Should we use a prefix like "eff-"? Should each effect have a standard class? How to handle variations on that class? Maybe like class="modal" data-modal-style="from-top" ?
• Are we doing the Sass thing or not? I don't care either way. If we do, we might wanna go Bourbon because it has keyframe stuff.
• jQuery or Raw?
• We need to standardize the JS for each module, and use as little JS as possible. Probably just click/touch handlers and state-changing classes.

[paulirish]

Repo created:

https://github.com/h5bp/Effeckt.css

Added everyone here to it. :D

You can take yourself off the team if you want, or just turn off notification if you'd rather keep things quiet.

[AaronLayton]

We can take all these questions over to the new Repo now ;-)

[AaronLayton]

I would say to create this with SASS (which I will make a start on when @chriscoyier commits) and there is enough of us here if we want to do a Less version aswell

[enjikaka]

@chriscoyier I'd say use Sass and raw JavaScript.

[i-like-robots]

I've added a couple of new threads over on the repo issue tracker:

Naming styles: h5bp/Effeckt.css#1 Sass, LESS etc: h5bp/Effeckt.css#2

[paulirish]

@i-like-robots thanks! @foleyatwork really appreciate your comment above. I think you're totally on point.

Alright a few of us are active over there... Let's carry on this conversation threads over there!

[SaraSoueidan]

I'd like to contribute to this! Starting with my windows-8 animations demo (that proved quite popular) : http://sarasoueidan.com/blog/windows8-animations/

and maybe this too: http://sarasoueidan.com/blog/ui-transitions-creative-add-remove-effects-for-list-items/

[Shahor]

Awesome !

[hakimel]

This is a great idea @paulirish. Cool to see how far it has come already! I don't have time to jump in on another project but definitely feel free to use any of my concepts/effects.

[paulirish]

thanks hakim!

[LeaVerou]

This is a great idea @paulirish. Cool to see how far it has come already! I don't have time to jump in on another project but definitely feel free to use any of my concepts/effects.

Ditto!

[davidpett]

I would love to contribute to this. I can't stand overdone/overused animations that make the experience a disaster. Simple elegant motion is what makes everything better