[cssom] `ComputedStyleObserver` to observe changes in elements' computed styles

[trusktr]

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:

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
• ComputedStyleObserver? css-houdini-drafts#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:

• Should resizing callbacks happen before animation frame? WICG/resize-observer#37
• When resize canvas , there is a white background flickering pixijs/pixijs#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.

[jimmyfrasche]

It would be quite useful to use this to reflect css state (combination of media/preference/container query and :hover/:focus etc) back into js by observing a custom property. Currently those either need to be tracked in parallel in the js (makes it hard to change anything) or handled entirely in js and have the js reflect the changes to css by adding and removing classes (annoying since it would be much easier to express in css)

[Loirooriol]

I guess simple cases could be covered by the already approved #6205?

element.firstChild.matchContainer("style(property: value)")).addListener(listener)

But yeah not the best API if the element doesn't have children or for properties with a non-trivial value space.

[trusktr]

Here's a related issue describing a problem that would need to be solved for ComputedStyleObserver (and any other new observers) if it (they) ever become reality (f.e. BoundingClientRectObserver):

• [resize-observer] why we need ResizeObserver.takeRecords() or ResizeObserver.hasRecords() (the canvas flickering problem) #9717

The more of these we add (which I think would be super useful) the more this problem will become pronounced.

Adding takeRecords and hasRecords to all *Observer APIs would help and would be useful.

Alternatively requestFinalFrame (or requestPaintFrame or some similar named API) would help solve the problem.

[PupilTong]

+1 for this proposal.
Let me give some detail about why we need this.
Currently we're working on a cross-platform rendering infra(like react-native). Developers using CSS syntax to define layout of the DOMs.
However, we provided some non-standard CSS properties for developers, since it's will gain some performance improvement on iOS/Android.
The way we implement it on Web platform is that we transform the some-property:custom-value to --some-property:custom-value on compile-time, and use getComputedStyle() in attributeChangedCallback to get the value of the css variables, then use Javascript to do somethings.
As you can see, here we could only observe on style and class attribute change, which means our handler will be called frequently(it' expensive since we have to getComputedStyle every time);
It will be really helpful if there is a way to observe specified CSS properties.

[jakearchibald]

https://static-misc-4.glitch.me/custom-property-observer/ - here's a little hack that uses style queries and resize observer to get close to this feature.

[bramus]

Another approach is https://github.com/fluorumlabs/css-variable-observer which I found a while ago.

It abuses the font-variation-settings property because that one can essentially hold <string> values (because <opentype-tag> = <string>). The property is set to transition really fast and by hooking up a transitionstart listener, the change is detected.

Demo using it: https://codepen.io/bramus/details/gOEoKrL (click the page to change the values of the custom props; the @property registration is not mandatory for the code to work)

Downside: the library only supports numbers because of how font-variation-settings is defined (i.e. [ <opentype-tag> <number> ]#), but I’m sure it could be altered a bit to make more values work.

[jakearchibald]

Huh, could some of the discrete value animation stuff be used to make this work for non-numbers?

[bramus]

Oh, Jake, that’s the clue I needed!

Here, a quick POC: https://codepen.io/bramus/pen/ZEdjjPw/1fa07805a7d6a6ea204decce87ee6705

I’m storing the value in content. Because content only accepts strings though, the value for --observed won’t make it into there. However, the transitionstart still fires because of transition-behavior: allow-discrete, so it’s possible to read --observed in the callback attached to it.

Blogpost incoming …

Update: Meh, doesn’t work in Firefox nor Safari 😭

[jakearchibald]

Surprised this doesn't work in Safari 18, given that it supports allow-discrete.