Transitions / Animations about axis

[jescalan]

Hey, great call. So right now it's only using animate.css which means we can just use their docs, but if we end up expanding it we certainly will need our own. I'm not totally sure on which ones should be included though, I pretty much never use gratuitous css animations personally, so this hasn't been something I've pushed. The two options you put up here are awesome though, definitely worth combing over.

I'm also on vacation now for a couple weeks so I'll be more passive, so no worries. Open source is open source, and we work when we can!

[jescalan]

Ok, so I have an idea for this. While I don't want to include massive animation libraries directly in axis, I would like to have another stylus library that holds on to some of these nice animation libraries people have made (like animate.css, magic, codrops stuff, etc) - whether this is a single library that you choose which one(s) you want to import as part of the options, or ports of each one as stylus wrappers, I think these could be useful utilities.

Is there anyone who would like to create a repo or some repos like this? I'm happy to work on some, but I'm maintaining a huge number of stylus plugins already at the moment, and would love to spread out the responsibility if you guys think you can manage. As a bonus, you get lots of github fame for having them under your name : )

/cc @yoshuawuyts @declandewet

[yoshuawuyts]

Nah, I'm good. Effeckt.css has got my needs more than covered. Good luck!

[jescalan]

It would still be great to have a stylus package for this : ) Does one exist already?

[yoshuawuyts]

Why would you want to package it? I believe most people just pick what they need and dump the rest.

[jescalan]

It would be an easy way to pull what you need into a stylus pipeline

[jescalan]

I guess what I'm getting at here is that I've recently been treating stylus plugins like packages, and npm can be used as a package manager for them. So rather than trolling through a repo and copy-pasting css before each project, you could run npm install effekt-stylus then drop that into your pipeline to have it in one clean package. From there, you could import the ones you need using @import in your stylesheets, which would make things really smooth and simple.

[yoshuawuyts]

Yeah, I pretty much do that using Bower.

[jescalan]

Is effekt on bower? And will it import cleanly into stylus?

[zspecza]

One Stylus lib to rule them all, one Stylus lib to find them - one Stylus lib to bring them all, and in the darkness bind them? Sounds like it'd be awesome but I have a feeling in my gut that says it's not a worthwhile idea given the amount of staying on top of updates that would be involved

[jescalan]

I mean it would mostly mean updating code when they have a new release. It's quite possible that this piece could even be automated actually. Converting css to stylus is a solved problem and it should be as easy as a build script that has to be run and published when they push a release.

I think it could potentially be extremely useful for those who bank more heavily on animations, I just dont that much personally.

[zspecza]

Perhaps we should have a chat some time about planning a build system that can do this, that kind of project seems most interesting cause it could have other uses as well... kind of like a modular CSS lib aggregation framework - which would probably be even cooler if it could normalize between preprocessors. :P

[jescalan]

True enough. Really I just want to bolster the stylus plugin community. We bank super heavy on stylus for all our projects over here and already have a lot of great plugins built. Stylus is an awesome preprocessor, it's actively maintained, and the stylus community isn't clogged up with amateur developers. Roots also has very robust support for keeping a stylus plugin pipeline. I want to get as many useful stylus plugins out there as possible and make sure they are well-built, tested, documented, searchable, and on npm.

Also a much bigger mission, but something that is big on my radar for the future.

Either way, I'll close this issue because it's not relevant to feature implementation in axis, but would love to continue this discussion