Skip to content
This repository has been archived by the owner on Apr 12, 2024. It is now read-only.

ng-animate-ref - Clone doesn't copy contextual styling of original #12402

Open
dweerd opened this issue Jul 22, 2015 · 5 comments · May be fixed by #14366
Open

ng-animate-ref - Clone doesn't copy contextual styling of original #12402

dweerd opened this issue Jul 22, 2015 · 5 comments · May be fixed by #14366

Comments

@dweerd
Copy link

dweerd commented Jul 22, 2015

When an ng-animate-ref element is cloned before an animation, I would expect it to look exactly the same as its source element. Instead, when the source element has styling applied because of the specific context it is in (e.g. .context .source-element { background: green; }), this styling is not applied to the cloned element.

This makes the animation weird: it first snaps to the styling the .source-element would have when in no context, and then animates to its new context. Example: http://plnkr.co/edit/AXzKmQcE5BUx4NXg4cCS?p=preview. When clicking an element, it first snaps to a blue background, before animating to a black background. I would expect it to animate directly from a green to a black background.

This can be worked around by simply applying all styling directly to the source element to be animated (e.g. .source-element-in-context { background: green; } (see this plunker: http://plnkr.co/edit/Odho9WnoOm9JFv3gzzZl?p=preview), but it makes much more sense to me when angular itself applies all styling of the source element to the cloned element.

@Narretz
Copy link
Contributor

Narretz commented Dec 2, 2015

Sounds resonable!

NickBolles added a commit to NickBolles/angular.js that referenced this issue Apr 4, 2016
Copy all contextual styling to the cloned element.
The list of properties that are copied is derived from
https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_animated_properties

Closes angular#12402
@NickBolles NickBolles linked a pull request Apr 4, 2016 that will close this issue
3 tasks
@NickBolles
Copy link

I believe this is the behavior you are experiencing. Your plunker link didn't exhibit the issue for me. http://plnkr.co/edit/OLhhDaz8awp5wzLoeAr1?p=preview

I have made a PR #14366

Here is the Plunker with the modified version of ng-animate
http://plnkr.co/edit/EvBFwIGD40pHxewXCYGY?p=preview

Let me know what you think!

@dweerd
Copy link
Author

dweerd commented Apr 4, 2016

Hm I guess something went wrong with the plunker or its url. But your plunker shows what i meant. Your example of the modified ng-animate looks good!

But thinking about this some more, I would also expect this to work in more advanced cases. For example:
http://plnkr.co/edit/iZB1Y5pKFtRsJ6SLqg0w?p=preview

In this case, the last row has a position: fixed. Right now it snaps before animating. It would be cool if angular would put the cloned element on exactly the same position as the fixed element is.

This also applies to width and height.

@NickBolles
Copy link

I agree. This is also an issue with elements nested inside the element and their contextual styles. I think there is only so much that you can do though.
The other method I was trying first was to call getCalculatedStyle() and use that as the new styles for the clone, but there are some issues with that that I couldn't get ironed out. I wonder if that method would be more smooth. Although it would come at the cost of performance probably.

NickBolles added a commit to NickBolles/angular.js that referenced this issue Apr 7, 2016
Copy all contextual styling to the cloned element.
The list of properties that are copied is derived from
https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_animated_properties

Closes angular#12402
@NickBolles
Copy link

Another example. ng-style causes this snapping behavior when going to an ng-style.
http://plnkr.co/edit/4QQ1RhHOsQ0w6lLKrJRY?p=preview

Compared to the modified:
http://plnkr.co/edit/TIQR2lv0Wa3zAwqeEhy0?p=preview

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

Successfully merging a pull request may close this issue.

3 participants