[css-layout-api] Need to select policy for selecting global scopes.

[bfgeek]

Do we want similar behaviour to the layout API? E.g.

• Select between at least 2 LWGS
• Must't use 1000 times in a row.

[css-meeting-bot]

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

The full IRC log of that discussion

<dael> Topic: Need to select policy for selecting global scopes
<dael> Github: https://github.com//issues/744
<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
<dael> surma: Limit to 2000?
<dael> iank_: It's because you need "fewer" code you don't know where the state will be
<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.
<dael> surma: THat's high
<dael> Rossen: That's why it's a not. If you're really constrained you can reuse it.
<dael> Rossen: Why would layout have a different policy?
<dael> iank_: I don't think there's a reason. Same would be good.
<dael> Rossen: I think this is how worklets works. Layout just follows.
<dael> iank_: Yeah. I think worklets is different because audio has different requirements. Whatever happens for the rendering type layouts.
<dael> Rossen: Other opinions?
<dael> smfr: If an author needs to do expensive computation it has to do it many times.
<dael> iank_: You can stash, but you have to be able to regenerate it.
<dael> TabAtkins: You'll prob get some statements.
<dael> smfr: So you'll have layouts that say every 30 times...
<dael> Rossen: If you get called by 30 worklets witht he same input you should work no matter the state of the laout
<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.
<dael> iank_: I think it's slightly different. WIth animation you want previous frame, but there's no reason you'd want that.
<dael> smfr: There's a whole opportunity for custom layout like moving boxes.
<surma> s/surma/cbiesinger/
<dael> iank_: That's fine if you feed the custom state.
<dael> TabAtkins: If it depends on layout it will not let you cache as much.
<dael> TabAtkins: [missed] The JS can send it straight in without redirecting through a custom property string.
<dael> flackr: If we switch to worker2 and back to 1 is that the same instance?
<dael> iank_: That's the next issue.
<dael> Rossen: Were there other reasons people believed we should have a different policy for worklets?
<dael> dbaron: I wouldn't phrase it that way becaues worklets might be used more broadly
<dael> Rossen: Fair enough. No different policy the paint
<dael> RESOLVED: Use the same worklet policy as Paint