ComputedStyleObserver?

[LeaVerou]

Just wanted to bring this WICG thread to the group's attention: https://discourse.wicg.io/t/observe-current-computed-style-changes-styleobserver/4879

I posted my thoughts about use cases there too:

Just came here to suggest the same thing.

Polyfills are indeed one use case. But IMO the main one is custom elements that need to propagate such changes to the appropriate child / shadow DOM node, or even rewrite them completely.

Examples:

• Implementing a custom element that works like <fieldset>, where border isn't applied to the whole element, but to the shadow DOM element wrapping the contents.
• Similarly, a border on a tabs component wouldn't be useful around the whole component, but should set the border of the tabs and the tab panels.
• To direct where a background declaration should be applied. E.g. right now there are dialog/popup components, where setting the background sets the backdrop color instead of the dialog background because of how they were implemented.
• To implement high-level custom properties that control multiple declarations, e.g. --tabs-placement: [top | right | bottom | left ], --size: [small | medium | large], --pill: [on | off ] which are currently typically implemented as attributes against TAG guidelines. I linked to Shoelace, but other component libraries are no different, Shoelace just has more linkable docs. :) This is not something that can be solved with ::part() or :state().

Besides propagating declarations to the appropriate child, there is also the opposite: listening to style changes on the children and adjusting ancestors appropriately. E.g. imagine a <pie-chart> component that uses <pie-slice> children to define the different segments, where a shadow <canvas> or conic-gradient background on the parent was used to render the pie chart. This is not implementable without the ability to listen to background changes on <pie-slice> and redraw the chart. And unlike propagating to children, this is not something that can be hacked via inherit and display: contents.

If a generic observer would be too hard, perhaps there could be something specifically for custom elements and slotted elements, like attributeChangedCallback but for CSS properties.

Would something like this be implementable?
I believe (correct me if I'm mistaken) that UAs are not actually listening to changes, but inspecting dirty flags on repaint, which makes implementation for something like this tricky. Would it make it implementable if such an observer explicitly registered a list of elements that should be observed and fired when they are actually repainted, and not the moment the style change happens? I believe this would still cover most use cases.

[gmurray81]

to add onto this, I personally don't think prompt notification of the change is especially important. Nice, certainly. But for all the practical purposes I have for this, it would be sufficient to know that an element under consideration had seen a change to it's styling environment so that some associated work and updates can be queued. It would be most flexible and useful if this was immediate, but if that would harm performance too direly, merely to know promptly would be sufficient.

[bramus]

To those finding this issue through search: https://brm.us/style-observer is a userland solution for this.