- From: Brian Birtles via GitHub <sysbot+gh@w3.org>
- Date: Tue, 14 Jan 2020 23:59:41 +0000
- To: public-css-archive@w3.org
[CSS transitions](https://drafts.csswg.org/css-transitions/#starting) has: > Since this specification does not define when a style change event occurs, and thus what changes to computed values are considered simultaneous, authors should be aware that changing any of the transition properties a small amount of time after making a change that might transition can result in behavior that varies between implementations, since the changes might be considered simultaneous in some implementations but not others. My concern is that while differences in the timing of transitions being triggered is unfortunate, unless they actually lead to a difference in the set of events being fired (which they _could_, but won't always), they're unlikely to cause catastrophic failure. Returning the animations in a different order, however, is more likely to. > When I discussed this with some style folks on blink they figured that interop incompatibilities about when style changes occurred would likely cause lots of interop issues. Maybe it's reasonable to try to achieve interop on when style changes should occur (at least with respect to developer APIs). Yes, that sounds good. I'm a little unsure how practical it is, though, since we'd need to define whether each DOM API flushes style and under what circumstances. We do that for some Web Animations APIs but most specs don't. -- GitHub Notification of comment by birtles Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4669#issuecomment-574431272 using your GitHub account
Received on Tuesday, 14 January 2020 23:59:42 UTC