Repository navigation
Conversation
Elchi3
left a comment
There was a problem hiding this comment.
Not really sure if these two add-ons are a feature on its own. If they are, I think we should try harder to mention what they offer.
| @@ -0,0 +1,9 @@ | |||
| name: Animation accessors | |||
| description: The `animation` property of an `AnimationEvent` or `TransitionEvent` object is the `Animation` object that triggered the event. | |||
There was a problem hiding this comment.
| description: The `animation` property of an `AnimationEvent` or `TransitionEvent` object is the `Animation` object that triggered the event. | |
| description: The `animation` property of an `AnimationEvent` or `TransitionEvent` object represents which Animation (and thus which element) fired a certain animation event. |
There was a problem hiding this comment.
I like your approach and adapted it into c4deaf6.
Co-authored-by: Florian Scholz <349114+elchi3@users.noreply.github.com>
So I found myself with three plausible paths here:
I initially wanted to lump it into If we had a feature merging apparatus already in place, I'd advocate for a fast merge, where a minor extension to an existing feature hits Baseline high means we immediately fold it into its antecedent feature. We could still do that, once we get feature merging in. Or we could say, yes, it would have been the correct thing to do three months ago, but since we didn't do the correct thing now, we should pretend it never happened in the first place and silently fold it in. That feels a little bit bad. |
Elchi3
left a comment
There was a problem hiding this comment.
Thanks for elaborating! I think I now agree that mining a feature is the better path forward. Should we leave a comment in the yml that says "Merge into animation-css when this feature becomes baseline high" ?
Fixes #4107