[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:

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.

Start with the existing ComputedStyleObserver implementation and the linked WICG discussions, then review the issue's polling, edge-case, performance, and callback-timing concerns. Done would require an agreed API and timing model that addresses these open design questions; the issue does not name implementation files or tests.