Re: [whatwg] Fetch Objects and scripts/stylesheets

On Tue, Jul 22, 2014 at 10:26 AM, Ian Hickson <ian@hixie.ch> 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.
http://lists.w3.org/Archives/Public/public-webappsec/2014Jan/0129.html
suggests the idea of using fetch for stylesheet subresources in the context
of subresource integrity.

> (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 18:02:18 UTC