On slower devices/browsers, transitions don't always work

[ajoslin]

On some older/slower devices or browsers (android and iOS), the transitions sometimes just don't work. It seems the transition class somehow doesn't apply itself.

src/change.js, line 37-49. Here's an explanation of how it works, for example with sliding a page in: It first applies a class which makes the page be hidden to the left of the screen (destClass), along with the class that marks it as a slide transition.

Then, after a setTimeout so the destClass has time to "apply" itself to the element going in, the element is set to transition into the middle of the screen with showClass. The problem is sometimes destClass just doesn't move the element; it doesn't do its thing.

On line 49 there's a temporary "fix" (not really a fix): the second class isn't added until 30ms later than the first class. But this doesn't even always work; sometimes when it's really slow even with 30 milliseconds the destClass won't "apply" itself.

Current ideas: 1) Figure out what the actual problem is with current class structure (will require more tweedling) 2) Change how I'm doing transitions with a different class structure (no concrete ideas yet) 3) Move away from classes and use el.css() - I don't like this at all. Takes away the ease of a stylesheet.

If anyone has any ideas for 1) or 2), please say :-)

[jrowny]

Maybe take a look at sencha. I'm pretty sure they do a slide transition with CSS3

[casio]

Probably unrelated, but I was wondering why you chose translateX over translate3d. Does this make a difference already? Dunno, maybe translateX already is hardware accelerated, but maybe it isnt.

Another optimization might be to instead having several addClass/removeClass calls after another(which will trigger their respective loops & calls), create your own class housekeeping based on strings and only do one final dest[0].className = destClasses.

[ajoslin]

thanks @jrowny! It seems Sencha uses keyframes. Keyframes are much better; they place the item outside the page and slides it in for you with one class.

@casio, thanks. I will use translate3d. I looked it up and it seems it depends on the device for translateX/Y, but everyone says 3d translations are always hardware accelerated.

And using the className thing .. I don't want to do that, because it doesn't allow the user of $change service to have any classes he wants already on the element (since I have to remove some classes sometimes, that would require a string replace which is also intensive).

[petebacondarwin]

I am away and can't look at this properly but in the collapse directive I found that reading the element's offsetWidth seemed to trigger the browser to evaluate its rendering.

https://github.com/angular-ui/bootstrap/blob/accordion/src/collapse/collapse.js#L14

Perhaps something like that would help here?

It is also worth looking at how jQuery mobile handles transitions since they have a lot of work arounds.

[jrowny]

I prefer CSS3 transform style to jQueryMobile because it just seems a lot smoother. The jQueryMobile version does work on a larger amount of browsers and devices.

[ajoslin]

Fixed in 453bc980.

I went with css3 animations still, using webkit keyframes.

The initial goal here isn't to support older browsers like jQuery mobile does. We only support webkit browsers at the moment.