- From: Amelia Bellamy-Royds via GitHub <sysbot+gh@w3.org>
- Date: Fri, 26 Apr 2019 19:37:59 +0000
- To: public-houdini-archive@w3.org
@isiahmeadows Sorry I missed your comment when you made it. So your idea is to skip the Class declaration and just use an options dictionary instead? I don't see any problem with that at a glance, but I was following the pattern of the existing Houdini APIs. Other people could explain better why the class pattern was chosen for the Paint and Layout APIs. That said, your example is fairly close to the custom property API, so maybe that's a better model. > There's a bit more detail specific to functions that we want to expose, which are needed for a good `--random()` function Ah, yes. I had thought of that, but it didn't make it to my write-up. Giving the custom function access to the property name shouldn't be too much trouble. There'd need to be another static function that declares the dependency on property name which warns the browser that it can't reuse the returned value across properties. And then pass in the property name as an additional parameter in the JS function. Similarly, another static function (or a registration option, if we go with the class-free proposal) could request that the inherited value gets passed in to the JS function, while warning that the function needs to be re-calculated when the inherited value changes. Making the function result dependent on the element is a little trickier, since we can't expose raw DOM objects to the worklet. But maybe each unique element could be represented by some sort of hash value that has no meaning of itself but could be used as a seed to a random function to ensure that you always get the same result for the same element but different results for different elements. -- GitHub Notification of comment by AmeliaBR Please view or discuss this issue at https://github.com/w3c/css-houdini-drafts/issues/857#issuecomment-487176511 using your GitHub account
Received on Friday, 26 April 2019 19:38:01 UTC