- From: Tristan Fraipont via GitHub <sysbot+gh@w3.org>
- Date: Sun, 01 Sep 2024 15:21:47 +0000
- To: public-css-archive@w3.org
Not to bring down the hype here, but I feel like one of the most important questions around this proposal is about the timing of the API. Currently all the "things" that have been built as "ponyfills" seem to be built on CSS transition events, but if the changes to the style have been done after the step 11 of of [update the rendering](https://html.spec.whatwg.org/multipage/webappapis.html#update-the-rendering) (i.e in a fullscreenchange callback, an animation frame callback, or a ResizeObserver callback), CSS transitions would fire one rendering frame too late, with the full change well painted on screen. I'm quite doubtful this would be acceptable for many use cases. Assuming its name is really `ComputedStyleObserver` I would assume it would fire whenever a recalc occurs, in the next microtask, similar to how `MutationObserver` works, even if that might mean several callbacks per rendering frame. This would at least allow preventing the change if needed. Also adding one more aggregation step in *update the rendering*, as seemingly proposed in the original comment, would seem wrong to me as this would lead the search for the closest place to the rendering just one step further *until the next episode*. Having it react to actual recalc, but aggregated in a microtask, would allow to handle most cases, even when the changes come from a `ResizeObserver` callback. -- GitHub Notification of comment by Kaiido Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8982#issuecomment-2323392021 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Sunday, 1 September 2024 15:21:48 UTC