Re: [whatwg] Fetch Objects and scripts/stylesheets

On Mon, Jul 28, 2014 at 12:51 PM, Ian Hickson <ian@hixie.ch> wrote:
>
> Ah, I see. Makes sense.
>
> Are there any cases where you'd know the headers you want to send at the
> time the markup is written, before JS is involved, or would you always be
> updating the fetch settings from script?


I think there are cases where we'd want to send data directly from the
markup. For example logging the fact that the load was initiated from the
preloader could be useful!

Also, I'm hoping that one of the things we could eventually accomplish with
exposing the fetch object is increasing the number of our scripts that are
accessible to the preloader. Today, Facebook avoids sending <script> tags
directly in the document -- there is quite a bit of JS on the Facebook home
page, but not all of it is needed to make the document interactive.
Therefore, we send JSON blobs of which JS files will be needed for the
document to our client side javascript code. This code schedules script
loading, only putting in non-critical JS after the critical JS is loaded.

By exposing the fetch object, we could take advantage of whatever
functionality the browser gives us to control prioritization. For example,
for clients using SPDY, if fetch exposed a way to set priority of the
request, we could expose all of our JS to the preloader and let our CDN
order it's response.

We can definitely expose the fetch settings in markup, e.g. in the
> trivialest sense just by embedding a JSON blob in an attribute, or maybe
> in a more friendly dedicated microsyntax. I just want to make sure that
> that's the right thing to do before we go down that path -- meaning, that
> it has sufficient use cases to justify it, rather than require consumers
> to set these settings from script.


I'd argue we're already expressing many of the fetch settings already. For
example, the crossorigin attribute exposes the mode of a fetch (
http://fetch.spec.whatwg.org/#concept-request-mode). The sub-resource
integrity spec provides a way to pass an integrity attribute to the fetch
algorithm (http://www.w3.org/TR/SRI/). Directly exposing fetch parameters
to the user could allow specification of this type of feature with adding
new attributes to every type of request. As mentioned earlier in the
thread, it could also help apply these attributes in difficult contexts
(eg, the source of a background image in a CSS file). While providing fetch
settings might not be the friendliest interface, I think this would be a
huge win for advanced web sites. I'd point out that for sites that are
advanced enough to benefit from this feature, they are highly unlikely to
be writing their code by hands -- their server side code is likely
generating the script tags to be inserted in their document.

Received on Monday, 28 July 2014 20:15:42 UTC