Re: [whatwg] Fetch Objects and scripts/stylesheets

On Mon, 21 Jul 2014, Ben Maurer wrote:
> 
> (1) Allowing the user to specify parameters to Fetch. For example, a user
> could say:
> 
> <script src="/my.js" params="{'headers':{'myheader':'value'}}"
> id="myscript" />
> 
> This would allow the user to make any type of request customization that
> they could for a direct call to Fetch.

I think this would make a lot of sense. It's similar to earlier 
suggestions for controlling "Referer" on a per-link basis, but more 
generic. The problem I had with the proposals for controlling Referer was 
that while there's an obvious way to do it for <script> and <link>, it 
quickly starts breaking down don't have a 1:1 mapping of URL to element. 
For example, how do you get the fetches of URLs in a style sheet? Or of 
the poster frame of a <video> element? Or EventSource objects? Should we 
just have different ways to set the options for each one?

   
> (2) Allowing the user to access the in progress fetch object. For 
> example, a user could say:
> 
> $("myscript").fetch.then(function(resp) { console.log(resp.status); })
> 
> Over time, the fetch object might add new functionality that would be 
> useful to the application developer. For example, I could imagine the 
> fetch object gaining a way to change HTTP/2 priorities mid-request. 
> Developers could take advantage of these functions for browser-initiated 
> fetches.

This would make sense to me also, but has the same API explosion problem 
where there's no obvious way to expose this consistently for everything.


> (3) Allowing the user to construct a script or stylesheet from a fetch. 
> Complex sites often want precise control over when scripts and 
> stylesheets are loaded and inserted into the DOM. For example, today 
> inserting a stylesheet blocks the execution of inline script tags. Some 
> sites may know that this dependency is not needed.

This specific use case is something I'm already working on. My long-term 
plan is to integrate something like this with the HTML Imports dependency 
model and the ES Module dependency model so that we have a single model 
that can handle everything.


> If one could construct stylesheets and scripts directly from a fetch, 
> the author could separate the act of fetching the stylesheet from 
> inserting into the DOM:

If we have a way to give dependency information for the <link> or 
<script>, we don't need to manually manage the dependencies at the Fetch 
object level.


> var myfetch = window.fetch(...);
> myfetch.then(function(resp) {
>   document.body.appendChild(resp.body.asStyleSheet());
> });
> 
> By calling asStyleSheet, the user could preserve the devtools experience 
> that exists today while still having complete control over the fetching 
> of their content.

We could do this too. It's mostly just a convenience method, right?


> (4) Giving the user explicit access to initiate fetches from the preload 
> scanner. One downside of the approach in (3) is that it doesn't take 
> advantage of the preload scanner to initiate fetches. I could imagine 
> offering the user an explicit way to trigger a Fetch from the preload 
> scanner:
> 
> <link id="foo" rel="fetch" href="/my.css" />
> $('foo').then(function(resp) {
>   document.body.appendChild(resp.body.asStyleSheet());
> });

This is exactly the kind of thing I'm looking at addressing with the 
aforementioned work on dependencies.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Tuesday, 22 July 2014 17:26:48 UTC