Re: [css-houdini-drafts] [css-layout-api] Need to select policy for selecting global scopes.

The Working Group just discussed `Need to select policy for selecting global scopes`, and agreed to the following resolutions:

* `RESOLVED: Use the same worklet policy as Paint`

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> Topic: Need to select policy for selecting global scopes<br>
&lt;dael> Github: https://github.com/w3c/css-houdini-drafts/issues/744<br>
&lt;dael> iank_: This one should be simple. Basically what is our policy for selecting global scopes. WIth paint API we set a policy that you must select between 2 and must not use more then 12 times in a row. What would we say for layout<br>
&lt;dael> surma: Limit to 2000?<br>
&lt;dael> iank_: It's because you need "fewer" code you don't know where the state will be<br>
&lt;dael> dbaron: Because you want impl to be able to throw away that state. Webdev shouldn't debug against code that doesn't throw it away.<br>
&lt;dael> surma: THat's high<br>
&lt;dael> Rossen: That's why it's a not. If you're really constrained you can reuse it.<br>
&lt;dael> Rossen: Why would layout have a different policy?<br>
&lt;dael> iank_: I don't think there's a reason. Same would be good.<br>
&lt;dael> Rossen: I think this is how worklets works. Layout just follows.<br>
&lt;dael> iank_: Yeah. I think worklets is different because audio has different requirements. Whatever happens for the rendering type layouts.<br>
&lt;dael> Rossen: Other opinions?<br>
&lt;dael> smfr: If an author needs to do expensive computation it has to do it many times.<br>
&lt;dael> iank_: You can stash, but you have to be able to regenerate it.<br>
&lt;dael> TabAtkins: You'll prob get some statements.<br>
&lt;dael> smfr: So you'll have layouts that say every 30 times...<br>
&lt;dael> Rossen: If you get called by 30 worklets witht he same input you should work no matter the state of the laout<br>
&lt;dael> surma: We have the idea that some aimations have a local state. The instance could provide a state object and if we construct we provide the state.<br>
&lt;dael> iank_: I think it's slightly different. WIth animation you want previous frame, but there's no reason you'd want that.<br>
&lt;dael> smfr: There's a whole opportunity for custom layout like moving boxes.<br>
&lt;surma> s/surma/cbiesinger/<br>
&lt;dael> iank_: That's fine if you feed the custom state.<br>
&lt;dael> TabAtkins: If it depends on layout it will not let you cache as much.<br>
&lt;dael> TabAtkins: [missed] The JS can send it straight in without redirecting through a custom property string.<br>
&lt;dael> flackr: If we switch to worker2 and back to 1 is that the same instance?<br>
&lt;dael> iank_: That's the next issue.<br>
&lt;dael> Rossen: Were there other reasons people believed we should have a different policy for worklets?<br>
&lt;dael> dbaron: I wouldn't phrase it that way becaues worklets might be used more broadly<br>
&lt;dael> Rossen: Fair enough. No different policy the paint<br>
&lt;dael> RESOLVED: Use the same worklet policy as Paint<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/744#issuecomment-379696520 using your GitHub account

Received on Monday, 9 April 2018 09:47:21 UTC