Re: [css-houdini-drafts] [css-paint-api] Use JS export instead of registerPaint

The Working Group just discussed `JS export vs. registerBlah`, and agreed to the following resolutions:

* `RESOLVED: Keep the current design`

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> Topic: JS export vs. registerBlah<br>
&lt;dael> github: https://github.com/w3c/css-houdini-drafts/issues/564<br>
&lt;dael> iank_: You can export things from a module should the engine be smart enough to crawl the export and pick off things that use paint.<br>
&lt;dael> iank_: Should we allow this in the spec?<br>
&lt;dael> surma: My reason was you can build tha ton the API we exposed.<br>
&lt;dael> surma: This seems more dev convenient, but I'm not sure how much they would experience the convenience since everyone is bundling.<br>
&lt;dael> surma: I think this is nice, but not worth the effort.<br>
&lt;dael> iank_: I think it's a bit of work for us. We don't have the onfirmation immediately exposed.<br>
&lt;dael> surma: Amy assumption that you can dynamically import and then tryand do exports, but if we don't have that you can't do it.<br>
&lt;dael> iank_: Do you think web dev coming to these APIs would expect...this is the first time an export could register<br>
&lt;dael> surma: We have used them, like the register call, which is not what I've seen in other APIs<br>
&lt;dael> dbaron: This may depend on how people persceve using them a couple years down the road. People who follow echnea script closely may have a better sense.<br>
&lt;dbaron> s/echnea script/ECMAScript/<br>
&lt;dael> fremy: You are supposed to be using import/export if you use modules, but I don't think there's an impression that the browser is pulling by default. I thought it was cool but if I have to write the funciton I'm not here.<br>
&lt;dael> majidvp: If you switch to exporting you don't know if it's paint or layout until you use module. BUt not when you register you register for a thing so you can verify.<br>
&lt;dael> iank_: Good point. Some oe fhte custom paint scripts we've seen people using it in the main winfow and the worklet. You can catch exceptions of registerPaint.<br>
&lt;dael> majidvp: Can you throw exception when you xport?<br>
&lt;dael> iank_: You can throw a global.<br>
&lt;dael> dbaron: Also search for where the function is. If it's export syntax I'm not sure how easy.<br>
&lt;dbaron> s/search for where the function is/you can search for the registerPaint name to find out what it does/<br>
&lt;dael> plinss: If we allow export we have to ad dmore clarity. You need another class to indicate this is a worklet. A bare export is really dangerious with extensible concerns.<br>
&lt;dael> iank_: It seems like an idea we'll keep for later if this becomes common.<br>
&lt;dael> Rossen: Sure.<br>
&lt;dael> flackr: Other way is at the point you add a module, naming the things you expect to be exported.<br>
&lt;dael> Rossen: Objections to keeping the current design?<br>
&lt;dael> RESOLVED: Keep the current design<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/564#issuecomment-379733903 using your GitHub account

Received on Monday, 9 April 2018 12:26:26 UTC