We're currently using jQuery animations for collapsible fieldset, autocomplete fadeout, tabledrag yellow warning and a pretty basic getEffect function in the ajax framework. That's all I found with a quick search.

They would be better off as CSS animations which can be better handled by mobile devices. IE before 10 doesn't support CSS animations, there won't be any functionality loss, it just won't be animated.

The state change should be handled by a class change instead of being hardcoded into our JS. We should have custom events firing before/after to allow contrib to change/cancel/react to an animation.

Currently there are still prefixes for js events at the end of a css transition, we can do some work to wrap that nicely for contrib use or just go with a (small) third partly lib that does it already.

There was some talk about having a more evolved animation system the same way we have an ajax framework (something more evolved and usable than the current ajax.getEffect method) not sure where that went but it could be a good time to think about it.

Comments

gmclelland’s picture

This might help

http://ricostacruz.com/jquery.transit/

Highlights
----------------------------
HOW TO USE
Just include this script after jQuery. Requires jQuery 1.4+.
Use $('...').transition instead of jQuery's $('...').animate. It has the same syntax as animate.

WHAT ABOUT OLDER BROWSERS?
jQuery Transit degrades older browsers by simply not doing the transformations (rotate, scale, etc) while still doing standard CSS (opacity, marginLeft, etc) without any animation.
Delays and durations will be ignored.

nod_’s picture

That's right. I did not want to link to it because we currently have 3 animated things in core and that is not worth 2k of JS.

Just want to keep it simple for our small use-cases. Some contrib-available API would be "nice to have" but it's not a blocker. It's not something possible right now so we wouldn't be loosing functionality.

gmclelland’s picture

This would also be handy if Drupal ever decides to do more animations with jquery.
http://playground.benbarnett.net/jquery-animate-enhanced/
This basically converts jquery animations into css3 animations.

I agree, we probably don't need a library for 3 animated things.

LewisNyman’s picture

CSS Transitions have JS events for the end of the transition. CSS Animations have more extensive event support.

I've never had to write a custom event yet.

nod_’s picture

Status: Active » Postponed

It's just too messy right now. Let's check back on it when the dust settle on browsers/jQuery implementations.

the issue with events is that browsers who don't support this will need special handling to trigger the callback, meaning more JS code for us defeating the purpose of this issue.

nod_’s picture

Issue tags: -JavaScript clean-up

tag

Wim Leers’s picture

There are a few issues with CSS transitions as is (off the top of my head):
- only a transitionEnd event, , no transitionStart event
- a CSS transition will only be applied if the CSS property you're trying to transition has already been rendered. So you actually need to know for certain that a certain property has already been rendered before changing it again (and thus triggering a CSS transition). Otherwise, it will just immediately show the eventual value. requestAnimationFrame() solves this problem, but it's unfortunately not available in many current browsers, and not at all on any mobile browsers! So, for now, you're more or less stuck with a setTimeout(callback, 0)

Recommended reading with partial solutions:
- nice overview of CSS transitions/animations/…: http://css3.bradshawenterprises.com/all/
- http://www.azarask.in/blog/post/animation-css-transitions-jquery-easy/
- http://snook.ca/archives/javascript/preparetransition-jquery-plugin
- setTimeout()/timer performance & power implications: http://www.slideshare.net/nzakas/javascript-timers-power-consumption-and...
- requestAnimationFrame() polyfill: http://paulirish.com/2011/requestanimationframe-for-smart-animating/
- requestAnimationFrame()-based performance improvements: http://www.html5rocks.com/en/tutorials/speed/animations/, http://blog.digitalbackcountry.com/2012/05/using-requestanimationframe-t...
- https://bugs.webkit.org/show_bug.cgi?id=27159

All of the above I was able to write thanks to the work I've been doing on Spark, specifically on the Edit module, which does use CSS transitions. There, I've decided to rely upon setTimeout(callback, 0) for now.

nod_’s picture

Until it's saner to use css-things let's continue with #209420: Remove the scrolling animation in collapsible.js

Wim Leers’s picture

I believe it is still worthwhile in simpler use cases, i.e where 1) the thing that needs to be animated does not need to be inserted on-the-fly (through custom JS code) and *then* animated, 2) it is not necessary to know when a transition ends.

Content inserted through Drupal's AJAX framework that contains DOM nodes that will be animated by CSS transitions should not be a problem at all.

I.e. in the case of the Edit module, we have to do some trickery. For most use cases, I think CSS transitions are fine.

nod_’s picture

Content inserted through Drupal's AJAX framework that contains DOM nodes that will be animated by CSS transitions should not be a problem at all.

It all depends on when attachBehaviors is called. If an attach behavior needs to know the size of a DOM element it probably won't work.

I mean for small things I'm all for it if it improves the UX and we don't need to know when it starts/ends.

nod_’s picture

nod_’s picture

Status: Postponed » Closed (won't fix)

It's fine now, less js animations even if we have much more CSS ones. Not a js issue now, more of a UX thing.