Re: [css-houdini-drafts] [worklets] <script> tag import feature design.

The CSS Working Group just discussed Worklets, and agreed to the following resolutions:

```
RESOLVED: Change preferred import to use <link> over <script>
```

<details><summary>The full IRC log of that discussion</summary>

```
<eae> Topic: Worklets
<dbaron> Github topic: https://github.com/w3c/css-houdini-drafts/issues/376
<eae> Github topic: https://github.com/w3c/css-houdini-drafts/issues/376
<eae> iank_: This topic is the design of the import. We could use a script tag or a link tag.
<eae> iank_: The script tag basically works as outlined in top comment of issue. Effectively you'd have a new type, i.e. type=paintworklet, always loads as module. Either with a src or inline.
<eae> iank_: The link tag version is basically what service worker does. Dominic outlined the proposal in comment 3 on the issue.
<eae> iank_: There are pros and cons for each.
<eae> iank_: Pro for script tag is that it matches what people do today and works with data urls. The downside is that it is running some code in a different global scope which is new and changes the script process model.
<eae> iank_: It is easier for implementers to implement th elink type but more powerful for authors to use a script tag.
<eae> eae: Optimizing for what is best for web developer has my vote.
<eae> Rossen: No opinions?
<nainar> Same for me
<eae> iank_: I could also defer to TAG on this one
<eae> dbaron: My only thought is that if there is a similarity with service worker it would be nice to use the same functionality with different names rather than have different approaches.
<eae> flackr: Related, the hack with the two instances of a worklet to avoid global state. Clearly not ideal but better than not having a way to discourage state. A way to maybe deal with this would be to have an execution context that cannot store global state. The syntax for loading worklets doesn't allow us to change how they are loaded right now. Would it make
<eae> sense for this to be versioned to possibly allow for another execution context down the line?
<eae> iank_: I think both proposals could handle that.
<dbaron> s/flickr/till/
<till> yes, thanks
<dbaron> s/flackr/till/
* eae thanks!
<eae> iank_: Taking dbarons feedback into account it sounds like the link tag is preferable.
<eae> dbaron: don't know how close this is to service worker
<eae> dino: Closer to service worker than inline so makes sense
<eae> philipwalton: You said in the first comment that there was various sources of feedback. Was any of it about supporting situations with js enabled? Would a link tag work in those cases?
<eae> iank_: Think that is a UA decision
<eae> iank_: If browsers have a preload scanner that could apply to <link tags.
<eae> iank_: With a <script tag and data url the memory cost would be higher, possibly.
<eae> philipwalton: link makes more sense to me.
<eae> Rossen: Sounds like we have consensus around link.
<eae> RESOLVED: Change preferred import to use <link> over <script>
```
</details>


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

Received on Tuesday, 18 April 2017 00:32:05 UTC