Re: [whatwg/fetch] preload, destinations, and module scripts (#486)

A couple more thoughts:

- Maybe we want to solve this subresources problem more generally, e.g. for CSS too.
- Do we also need something special for prefetch? Remember, preload is a declarative fetch for the current page; prefetch is a hint that the user will probably want this in their HTTP cache sooner rather than later.

This leads me to the following proposal:

- A new link rel="modulepreload" to do a declarative fetch of an entire module dependency graph for the current page, placing the result in the module map (but not evaluating it). This is a special enough semantic it makes sense to mint a new rel.
- Optionally, a new attribute, `includesubresources`, so that you can do `<link rel="prefetch" href="module.js" includesubresources>` or `<link rel="prefetch" href="style.css" includesubresources>` or even `<link rel="preload" as="stylesheet" href="stylesheet.css" includesubresources>`.

In this world, `preload` by itself doesn't work great for modules. That seems fine, unless we want to create 4 new destinations (modulescript, moduleserviceworker, modulesharedworker, moduleworker) and give them each somewhat-magic semantics where includesubresources implies modifying the module map, instead of the preload cache.

I'll work on modulepreload now, but still would love to hear more...

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/486#issuecomment-281787499