[css-properties-values-api] Observer for property being applied?

[LeaVerou]

Apologies if there's already a draft for this, I haven't been fully keeping up with Houdini. I did look though :)

People often use custom properties to invent their own DSL for augmenting existing HTML elements.
Some examples:

http://endtwist.github.io/kerning.js/
https://plugins.mavo.io/plugin/importhtml
https://tilemill-project.github.io/tilemill/docs/manual/carto/
and many more

However, this is really difficult right now even if properly using -- Custom Properties because there's no way to react to when these properties are applied to an element.

The only way to get them to have any nontrivial effect is to either:

• Get all elements in the page, get their computed style, check if the property applies
• Get all selectors in all stylesheets that use this custom property, join them with commas, and make one giant querySelectorAll() query.

Not only are both these approaches terrible, but even with them, there's no way to react to changes, e.g. when a pseudo-class applies.

It would be great to have an observer for this, even if it only worked with custom properties (perhaps only defined custom properties?).

[upsuper]

Would applyingtransition to the property then listening to transitionend event work here? Maybe we can reuse that mechanism somehow (so that we don't need to invent another concept and handle the interaction with animation and transition again)?

[LeaVerou]

Aren't events a bit slow for things like that?

[tabatkins]

Observers are no slower than events; they work on the same mechanism and timing. (There's some slight performance implications one way or another, but they're rarely relevant.)

---

This is planned for P&V level 2. The lack of it is definitely a recognized weakness in the current API; it just adds a lot more complexity that we're hoping to avoid with level 1.

[css-meeting-bot]

The Working Group just discussed Observer for property being applied?, and agreed to the following:

• RESOLVED: Add custom property observers to L1 of Properties and Values

The full IRC log of that discussion

<dbaron> Topic: Observer for property being applied?
<dbaron> github: https://github.com//issues/555
<heycam> TabAtkins: this has been something we're aiming for at some point
<heycam> ... you want to be able to observer when and where a given custom property is put on an element
<heycam> ... right now the best you can do, is you can do some processing on a custom prop, tell what grammar it's meant to have
<heycam> ... you can't say that for every element with this property, do this JS
<heycam> ... only way right now is to walk the tree and ask the style for every element, not great to do in a tight loop
<heycam> ... we already have things like this
<heycam> ... you can use the transition events to get at this
<heycam> ... but that's hacky, clearly
<heycam> s/you can use/xidorn pointed out you can use/
<heycam> ... we're planning on this for level 2
<heycam> ... at minimum, to observer specified values
<heycam> ... and older proposal shunted out is for computed value hooks, don't know if we want to do that immediately
<heycam> ... we have to define in more detail how that interacts with animations and transitions, which is complicated
<heycam> ... so at least getting the specified value out of things is probably worthwhile
<heycam> ... so we could put it in this level, or wait to the next level
<heycam> iank_: this would only be useful for non inherited properties
<heycam> ... otherwise you are going to walk the whole tree anyway, because everything is ...
<heycam> TabAtkins: you would only do it for everything that doesn't have the initial value
<heycam> shane: unless, like observers, they're applied prer element
<heycam> ... in which case the inheritance doesn't matter
<heycam> iank_: I think the use case is that you want to do some computation ...
<heycam> shane: here's an example from a script that does this
<heycam> ... a bunch of things they need extra JS for
<TabAtkins> http://endtwist.github.io/kerning.js/
<heycam> TabAtkins: so I think it will be find on specified values for now
<heycam> s/shane: here's an example/TabAtkins: here's an example/
<heycam> iank_: we're getting someone ramped up to finish teh P&V implementation
<heycam> ... ahd it landed behind a flag for 18 months now
<heycam> ... getting it finished off next quarter
<heycam> ... given the number of cool demos, shipping it before Christmas
<heycam> Rossen: end of 2018
<heycam> iank_: probably earlier
<heycam> Rossen: the reason I'm asking, is the current proposed feature for Level 1, that's fine, it's still a WD
<heycam> ... so I'm curious whether you're pressing to start shipping, we might need to start stabilizing this spec
<heycam> Rossen: with that said, I think it's still worthwhile to take this in L1 and see if we can make progress
<fantasai> TabAtkins: Anyone else have implementation?
<fantasai> heycam: We have half an impl, might pick up again in Q4 but probably not ready to ship in Q4
<heycam> TabAtkins: I'm going to fill in the parser section on how to parse a grammar string
<heycam> ... obvious but handwavy
<heycam> ... I have a lot of edits to apply to the spec
<heycam> Rossen: for this particular issue, we are resolving to have the observer for custom properties in L1, see how it goes
<heycam> ... concerns or objections?
<heycam> fantasai: I would say mark it as risk, I know we're not in CR now
<heycam> Rossen: we can do it once we get closer to CR
<heycam> dbaron: one other comment is, I think this is at a stage where it's ok to be adding new features, as long as they're reasonably solidly specified off the bat
<heycam> ... so I think it's ok to add this if the text gets written relatively soonish and gets reviewed relatively soonish
<fantasai> +1 to dbaron
<heycam> TabAtkins: I can promise to have the text written, and do as many other edits as I can, by the end of this meonth
<heycam> fantasai: stabilizing for CR takes time, we don't want freshly added text that is shaky
<heycam> dino: the way this spec is now, it allows you to specify a way to interpolate custom props
<heycam> iank_: you can define it to be non inherited
<heycam> ... and also give it an initial value
<heycam> TabAtkins: and a level of grammar checking
<heycam> dino: parse errors
<heycam> TabAtkins: yes
<heycam> iank_: a lot of demos atm are using it for animation, Ana Tudor has a bunch
<heycam> ... that's probably the biggest value as a standalone spec
<heycam> TabAtkins: this feature will be a huge uptick in use cases, when you can tell what elements have that element applied
<heycam> TabAtkins: so you think it should go in L1 to increase the value of the spec
<heycam> dino: I'm not necessarily saying that
<heycam> ... but I'm fine with it
<heycam> philipwalton: do we have any other observers?
<heycam> ... are we thinking too small just looking at custom properties?
<heycam> TabAtkins: possibly
<heycam> ... the API shape that's in my head right now can definitely work with any property, just a string name
<heycam> ... only defined it for custom properties at the moment, but no objection to widining it if there's reasonably use cases and implementation issues
<heycam> ... I know we handle custom props a bit differently from regular props
<heycam> ... if you have use cases, please put it into the issue
<heycam> philipwalton: I think a lot of these use cases would be handled by calc() on the property
<iank_> Ana Tudor demo: https://codepen.io/thebabydino/pen/MrZvNm (chrome canary + flag)
<heycam> dino: might be nice to put more examples in, beyond animations
<heycam> ... parse errors, non-inheriting, ...
<heycam> TabAtkins: definitely
<heycam> iank_: [demos]
<heycam> dino: so she's registering custom props for height, shadow, width, ...
<heycam> iank_: specifying things as angles, numbers
<heycam> ... and then she's plumbing them into a huge transform effectively
<heycam> ... so you can see scale affects fy, ...
<heycam> ... all driven by one big transform, but animating different parts of the animation separately
<heycam> ... and then setting a bumnch of animations on it
<heycam> TabAtkins: it's being driven by one big transform prop, but indepednent animations on bits of it
<heycam> TabAtkins: this is a one element demo
<heycam> ericwilligers: this is one of the motivations for the separate translate/scale/... props
<heycam> frremy: she also has a demo animating gradients
<heycam> TabAtkins: several examples of gradient animation
<heycam> RESOLVED: Add custom property observers to L1 of Properties and Values

[upsuper]

Regarding the design of this API, I would hope it to happen only when style flush happens, and the observer can get a list of elements which get updated on the property being observed during this style flush.

In Gecko, we compare each property for elements get restyled and invalidate stuff accordingly. I suppose other engines do something similar, so it would be closer to mechanism inside implementations.

[jsantell]

Working with web components that control 3D scenes via CSS over the last few months and just finding this issue now and very excited to see this feature 😄 other solutions involve significant performance hits (polling + getComputedStyle) or fragile (MutationObservers), and other solutions for responding to style changes do not work when wanting side effects outside of the changed element (otherwise, Paint Worklets would suffice).

Are there any rough timelines or sketches for how this API would work? Any other information or resources regarding this feature?

[keithclark]

Like Jordon, I've been exploring the use of web components to control 3D objects in HTML documents. I would find an observer that reacts to CSS property value changes really useful in these and other (non-3D) projects.

I'd like to have an observer that works with every property though, not just the custom ones.