Re: [w3c/webcomponents] observedStyles (#856)

Just posted a few use cases in w3c/css-houdini-drafts#1010 since I was unaware of this issue.

> 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 ]`](https://shoelace.style/components/tab-group?id=tabs-on-left), [`--size: [small | medium | large]`](https://shoelace.style/components/input?id=sizes), [`--pill: [on | off ]`](https://shoelace.style/components/input?id=pill) which are currently typically implemented as attributes [against TAG guidelines](https://w3ctag.github.io/webcomponents-design-guidelines/#:~:text=Don%E2%80%99t%20use%20custom%20attributes%20for%20styling). 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.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/856#issuecomment-708487002