- From: Domenic Denicola <notifications@github.com>
- Date: Thu, 24 Aug 2017 19:51:15 +0000 (UTC)
- To: whatwg/fetch <fetch@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <whatwg/fetch/issues/486/324738865@github.com>
> do you see the combinatorial possibilities extending beyond these four? Yes; we just added service worker in the last year or so. The future of the web is long. > I'm don't see how this is a strong argument for a new rel otherwise. I'll try to be more clear. Breaking the mapping of destinations to as="" values is pretty bad no matter what. We have a serious conflict here between destinations as they're used in fetch (both classic and module scripts go through as="script"; both classic and module workers go through as="worker"; etc.), and as="" as it's used in preload (we need to distinguish between classic and module scripts/workers/etc.). We need some way to signal "destination=script but treat it as a module script". as=modulescript is a pretty bad way to do that because it breaks the correspondence between as="" and destination. > I'm advocating rel=preload simply because the naive user-facing conceptual models of the web should embrace outward simplicity and reusability as far as possible to remain understandable to all, but I'm more than happy to step back on that if there are untenable spec differences here. Kind of the point of my post above is that there are untenable spec, implementation, and mental model differences here. It seems you didn't find it convincing, so I think it's a good exercise to go through and help me expand on the points; maybe you can provide your own summary if I manage to convey enough information, and that will be more convincing to others. But it's my strong feeling that based on available evidence, the differences are too large. > Note also that I'm not trying to throw out the concept of a full graph preload entirely - simply to say that what is needed urgently is a spec that will allow a low-level network-layer caching of module resources. Well, we already have that in HTTP/2. So I'm not sure how urgent it is. But yes, it'd be nice. Anyway, as I said above, I don't think recursive vs. not is a very interesting aspect of this whole discussion. I think it'll be about as easy to implement either one; maybe a bit easier to implement the recursive one. The hard parts are unrelated to recursive vs. not, but about fetch destinations, credentials modes, etc. -- 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-324738865
Received on Thursday, 24 August 2017 19:51:38 UTC