Re: [whatwg] Fetch Objects and scripts/stylesheets

On Tue, Jul 22, 2014 at 11:01 AM, Ben Maurer <> wrote:

> On Tue, Jul 22, 2014 at 10:26 AM, Ian Hickson <> wrote:
>> 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?
> I guess the upshot of of doing this through fetch is that once we added
> the ability to specify fetch metadata it would hopefully reduce the need
> for future modification of all the different ways one could load an object.
> suggests the idea of using fetch for stylesheet subresources in the context
> of subresource integrity.

That's intriguing. Does fetch() have any dependencies on the javascript
context? IIUC, a big motivator for element attributes for headers is
allowing the preloader to issue resource requests without bouncing back
through the main thread. Without knowing too much about fetch(), I'd be
curious if that achieved your goals.

The kind of translation I imagine happening is the DOM explaining resource
requests by exposing the Request object that Fetch is defining as an
attribute on the DOM element. And then you could have both a declarative
and imperative interface for modifying Request.Headers.

> > (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.
> This sounds interesting. The way we render pages at Facebook seems very
> similar to what you are suggesting. We essentially flush sections of HTML
> with a list of CSS and JS dependencies for each section. The HTML is only
> rendered once these resources are loaded. In essence, it seems like we're
> doing inline HTML imports. We have a few other use cases for this type of
> dependency (for example, we have a method where you can say "call this
> callback once resources X, Y and Z are requested".
>> > 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?
> One advantage of doing this is that if there is some use case a site has
> that isn't met by the dependency model they can still manually separate the
> fetch of an object from its insertion into the DOM. Giving the author the
> freedom to manually separate the fetch of a resource from it's use in the
> document gives them a powerful ability to experiment with different
> approaches to resource loading. asStyleSheet/asScript wouldn't merely be a
> helper method to construct a stylesheet from a given string of text. For
> example, line numbers in developer tools (or JS stack traces) as if they
> were loaded directly from the given URL. A browser might decide to parse
> the JS/CSS in a background thread as soon as the document was fetched (or
> cache a pre-parsed version of the file).
> This model also might be beneficial for sites that were written prior to
> the dependency model you are describing. For example, at Facebook we
> already schedule JS/CSS loading ourselves. This API would allow us to do
> things like fetch a CSS stylesheet without blocking inline script execution
> that follows while making a minimal number of changes to the site.
> -b

Received on Tuesday, 22 July 2014 19:06:22 UTC