- From: Jake Archibald via GitHub <sysbot+gh@w3.org>
- Date: Tue, 03 Dec 2024 13:08:36 +0000
- To: public-css-archive@w3.org
The Safari implementation is definitely wrong, as it violates the intent that [transitions are an enhancement](https://www.w3.org/TR/css-view-transitions-1/#transitions-as-enhancements). > That means a failure to create a visual transition, which can happen due to misconfiguration or device constraints, will not prevent the developer’s [UpdateCallback](https://www.w3.org/TR/css-view-transitions-1/#callbackdef-updatecallback) being called, even if it’s known in advance that the transition animations cannot happen. > > For example, if the developer calls [skipTransition()](https://www.w3.org/TR/css-view-transitions-1/#dom-viewtransition-skiptransition) at the start of the [view transition lifecycle](https://www.w3.org/TR/css-view-transitions-1/#lifecycle), the steps relating to the animated transition, such as creating the [view transition tree](https://www.w3.org/TR/css-view-transitions-1/#view-transition-tree), will not happen. However, the [UpdateCallback](https://www.w3.org/TR/css-view-transitions-1/#callbackdef-updatecallback) will still be called. It’s only the visual transition that’s skipped, not the underlying state change. It'd be nice to remove the race condition somehow though. -- GitHub Notification of comment by jakearchibald Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11292#issuecomment-2514515445 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 3 December 2024 13:08:36 UTC