As a developer I want to preload a resource that will be consumed by...

[igrigorik]

Current integration with Fetch API (as is mapped to Request.type) enables the following use cases:

consumer	Preload directive
<audio>	<link rel=preload as=audio>
<video>	<link rel=preload as=video>
<script>, Worker's importScripts	<link rel=preload as=script>
<link rel=stylesheet>, CSS @import	<link rel=preload as=style>
CSS @font-face	<link rel=preload as=font>
<img>, <picture>, srcset, imageset	<link rel=preload as=image>
SVG's <image>, CSS *-image	<link rel=preload as=image>
XHR, fetch	<link rel=preload as=...> ❓
Worker, SharedWorker	<link rel=preload as=...> ❓
<embed>	<link rel=preload as=...> ❓
<object>	<link rel=preload as=...> ❓
<iframe>, <frame>	<link rel=preload as=...> ❓

We need to enable the last five. What's the best route to do so? Fetch's current definition for Request.type does not have enough granularity to distinguish between these.

[igrigorik]

IRC log of #whatwg discussion: http://logs.glob.uno/?c=freenode%23whatwg&s=2+Feb+2016&e=2+Feb+2016#c983589

[yoavweiss]

If I read the IRC discussion correctly, its conclusion is that new destinations would be defined, in accordance with the spreadsheet.

Is that correct?

If so, I like the general idea, but have a few comments:

• The old "worker" destination cannot become "script" as it's subject to the "child-src" CSP policy.
• At least from preload's point of view, a few new destinations can be merged: "fetch" and "subresource", "sharedworker" and "worker", and "object" and "embed". If there are other reasons to keep them apart, I'm fine with that too, just wanted to stress out that the split for these destinations is not required for preload.
• Should we address ES6 modules here as well?

[igrigorik]

@yoavweiss see whatwg/fetch#211 for the proposed list, let's take this feedback there?

The old "worker" destination cannot become "script" as it's subject to the "child-src" CSP policy.

See w3c/webappsec-csp#31.

At least from preload's point of view, a few new destinations can be merged: "fetch" and "subresource", "sharedworker" and "worker", and "object" and "embed". If there are other reasons to keep them apart, I'm fine with that too, just wanted to stress out that the split for these destinations is not required for preload.

Yes, but I do believe it's required for destination's other users. For us (preload), that's fine though: more granular is OK.

Should we address ES6 modules here as well?

What about them, specifically?

[yoavweiss]

The "worker" comment was based on a misunderstanding regarding the spreadsheet. whatwg/fetch#211 covers everything.

About ES6 modules, I guess the question is if they will be treated as script (and subject to script-src) or as a separate resource type. I'll raise that question on the fetch issue.