Re: [css-houdini-drafts] [css-paint-api] Cycle possible using inputProperties() (#877)

The Houdini Task Force just discussed `Cycle possible using inputProperties()`, and agreed to the following:

* `RESOLVED: We go with AmeliaBR's suggestion, for which input custom properties create edges in the custom property graph`

<details><summary>The full IRC log of that discussion</summary>
&lt;Rossen_> Topic: Cycle possible using inputProperties()<br>
&lt;Rossen_> github: https://github.com/w3c/css-houdini-drafts/issues/877<br>
&lt;emilio> flackr: we realize that with paint worklet you can specify an image as an input property, which can itself be backed by another worklet<br>
&lt;TabAtkins> q+<br>
&lt;AmeliaBR> q+<br>
&lt;emilio> flackr: so you can in theory, once we implement the TypedOM &lt;image>, you could specify a cycle<br>
&lt;emilio> ... so there are multiple ways we could go about it<br>
&lt;emilio> ... we could try to spawn the paint worklet<br>
&lt;emilio> ... or try to prevent recursion somehow<br>
&lt;Rossen_> ack TabAtkins<br>
&lt;emilio> TabAtkins: the notion of CSS image generator values is not in any spec right now<br>
&lt;emilio> ... we could separate it<br>
&lt;emilio> ... we have cycle detection for custom properties<br>
&lt;emilio> myles: and then what?<br>
&lt;emilio> TabAtkins: you'd get a broken image<br>
&lt;emilio> myles: the whole chain?<br>
&lt;emilio> TabAtkins: yeah, probably<br>
&lt;emilio> heycam: how do you use the image values in the worklet?<br>
&lt;emilio> TabAtkins: you can pass them to drawImage<br>
&lt;Rossen_> ack AmeliaBR<br>
&lt;emilio> AmeliaBR: there are lots of very sensible use cases for reusing the paint worklet result from another paint worklet<br>
&lt;emilio> ... even the same worklet<br>
&lt;emilio> TabAtkins: that's true, so probably we don't want to use cycle detection<br>
&lt;emilio> ... but just depth detection<br>
&lt;emilio> AmeliaBR: cycle detection is fine, but not if you refer to the same worklet<br>
&lt;emilio> TabAtkins: I don't see the difference<br>
&lt;Rossen_> q?<br>
&lt;emilio> AmeliaBR: I talk about the case in which says paint(tiling) and another that uses paint(tiling) that depends on the first output<br>
&lt;emilio> TabAtkins: ok, so proper cyclic detection would work<br>
&lt;emilio> AmeliaBR: when you have a paint reference you treat them as bare references to the input custom properties<br>
&lt;AmeliaBR> s/bare/var()/<br>
&lt;emilio> whoops<br>
&lt;AmeliaBR> s/properties/properties, and then use the regular custom property cycle detection/<br>
&lt;AmeliaBR> s/whoops//<br>
&lt;emilio> myles: is this something that needs to be spec'd?<br>
&lt;emilio> ... HTML depth is not in any spec<br>
&lt;emilio> TabAtkins: CSS defines minimum depth and such though<br>
&lt;Rossen_> q?<br>
&lt;emilio> dbaron: it's also useful just to document so that people can pay attention to it<br>
&lt;TabAtkins> emilio: I agree that going for depth, the particular limit needs to be in a spec.<br>
&lt;TabAtkins> emilio: But the cusotm property cycle detection is in a spec.<br>
&lt;TabAtkins> emilio: So if we eagerly detect cycles, how to detec taht is needed.<br>
&lt;TabAtkins> emilio: And how to treat it.<br>
&lt;emilio> TabAtkins: if we do what AmeliaBR says then it's already in the spec<br>
&lt;emilio> RESOLVED: We go with AmeliaBR's suggestion, for which input custom properties create edges in the custom property graph<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/css-houdini-drafts/issues/877#issuecomment-499922873 using your GitHub account

Received on Friday, 7 June 2019 15:10:14 UTC