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

We’re doing this currently in some places within a RAF loop. This has taken two forms:

1. A property which is just e.g. keyword values, where reading the computed value implies interpolation of vars but interpretation of the value is simple.
2. A property which expects e.g. `<length>`, where a useful computed value needs to end up in px form. If the usage of a value of this sort is 1:n with some existing CSS properties, no observation is needed, but if the realization of the styling effect involves ES-layer calculation or secondary effects, it is.

As far as I’m aware, the former case doesn’t trigger paint or layout. The latter may: a workaround for it is to use an existing `<length>` property on an internal dummy element and read that, e.g. `<div style="top: var(--the-actual-property, 0px);">`.

For a few property reads like this, this is pretty harmless, but I don’t think it would scale acceptably for cases where numerous elements respond to custom properties.

While the usages we have had for these strategies to date have happened to track closely to element definitions, conceptually the properties don’t ‘belong’ to the element, and indeed there are cases where more than one element honors the same custom-property-whose-realized-effect-cannot-occur-in-css-alone. So I don’t think this belongs to the custom elements API, but rather to CSS APIs. The issue is closely related to `registerProperty`, which will simplify interpretation and help avoid hacks when available in all browsers, and also closely related to various Houdini efforts: at least one of the properties in question could probably be realized through the Houdini Layout API for example.

In other words I think this is a real need for authoring custom elements, especially UI widgets, that have coherent and consistent APIs that separate styling concerns from semantic concerns, but I don’t think it really belongs within the custom elements API.

-- 
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-557943115