- From: Robert Flack via GitHub <sysbot+gh@w3.org>
- Date: Fri, 06 Aug 2021 21:01:12 +0000
- To: public-css-archive@w3.org
Overall this makes sense. I think this is pretty consistent with how you cannot affect animations on descendants using variables due to the animation-tainted rules, though we should revisit those since I think instead of tainting the variables they should use the after-style values. I remain somewhat concerned about the potential performance cost of multiple layouts, and how easy it will be to understand when some container query animations do not run because the container query was triggered as a result of animation. The latter is already somewhat of an issue with animation-tainted variables and should be addressable with good tooling. > > One notable difference with the proposal is that I think setting a property equal to its current animation value normally would have no effect but with your proposed change would start a transition. We could probably carve out an exception for this given that we need to compute the current value to start from anyways. > > Not sure if by "current animation value" you mean only effects from CSS/Web-Animations, only effects from transitions, or effects from all of them. > > For _transitions_ happening on the same element, it looks like the [transition would be canceled](https://www.w3.org/TR/css-transitions-1/#starting:~:text=If%20the%20current%20value%20of%20the%20property%20in%20the%20running%20transition%20is%20equal) in both the current and proposed behavior. Ah yes, it seems the starting of transitions is already attempting to do something like the proposal here where we look at the non-animated values. I checked and it looks like the reverse-adjusting duration behavior should also work correctly. > For CSS/Web _animations_ happening on the same element, I think you're right. And yes I suppose we could check the current value for any animations and special-case on that, if necessary. Normally, transitions would not see style changes on elements with active animations because the animation has a higher composite order than the underlying style. I think we'll just need to have a special case here to not start transitions on an element that is currently animating. > However, it probably makes more sense to specify that the computed values of `animation-` and `transition-` properties on the animated style are forced to the corresponding values on the after-change style. That way `gCS()` matches reality to a greater degree. I agree, the getComputedStyle of "not animateable" properties should be their after-change style. -- GitHub Notification of comment by flackr Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6398#issuecomment-894515870 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 6 August 2021 21:01:14 UTC