[csswg-drafts] [cssom] ComputedStyleObserver to observe changes in elements' computed styles (#8982)

trusktr has just created a new issue for https://github.com/w3c/csswg-drafts:

== [cssom] ComputedStyleObserver to observe changes in elements' computed styles ==
We need an API to observe computed style changes.

One example use case is to update canvas rendering based on changes in computed styles of an element (f.e. `transform` values to determine where to draw things in a canvas).

This would be generally useful for implementing things that CSS cannot do, or making early polyfills of new CSS features that haven't landed in browsers yet.

What could it look like? Taking a note from existing observers:

```js
const callback = entries => {
  entries.forEach(entry => {
    console.log(`Property '${entry.property}' changed from '${entry.previousValue}' to '${entry.value}'`);
  });
}

let observer = new ComputedStyleObserver(callback);

observer.observe(someElement, ['background-color']);
observer.observe(otherElement, ['transform']);

// ... later
observer.unobserve(someElement)
// or unobserve all
observer.disconnect()
```

Some things like callback timing need to be ironed out. Maybe its timing would be aligned with animation frames like ResizeObserver.

Existing ideas and conversation:

- https://github.com/keithclark/ComputedStyleObserver
- https://discourse.wicg.io/t/observe-current-computed-style-changes-styleobserver/4879
- https://discourse.wicg.io/t/a-way-to-observe-changes-in-css-custom-properties/2738
- https://github.com/w3c/css-houdini-drafts/issues/1010
- https://jonneal.dev/blog/observing-css/
- https://dev.to/oleggromov/observing-style-changes---d4f
- https://stackoverflow.com/questions/13186427/fire-an-event-when-dom-elements-computed-style-changes

The main take aways from these are:

- simple implementations involve a non-ideal infinite polling loop with rAF
- correct implementations are cumbersome and difficult to do correctly, easy to miss edge cases, or perhaps even impossible to fully realize
- performance is not good

---

While we're making a new API, we can also see about avoiding the same problem that ResizeObserver has:

- https://github.com/WICG/resize-observer/issues/37
- https://github.com/pixijs/pixijs/issues/3395

The problem is that rendering loops typically redraw in animation frame callbacks, but if CSS style change callbacks run after rAF, rendering can be delayed and incorrect and it isn't obvious why.

Maybe the initial set of callbacks for change entries should fire before rAF? Giving typical rendering setups a chance to usually be correct and only sometimes needing an additional next frame for cases when a frame changes style. I'm not totally sure what the solution should be, but it has been a pain debugging these sorts of issues.

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8982 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Saturday, 17 June 2023 07:16:45 UTC