On Mon, Sep 8, 2014 at 7:59 PM, Ian Hickson <i...@hixie.ch> wrote:

> > The platform is missing a lower-level primitive (declarative and
> > imperative) that is able to explain resource loading with the same
> > expressive power as requests initiated by the browser itself.
> That isn't a problem.

I don't follow. To me that *is* the core problem that we should solve first
and ship as soon as possible: if we keep the surface area low, we can ship
it quickly and let developers experiment and move the platform forward.
Adding more layers of higher-level APIs only slows the deployment process.

To be clear, I'm not against the core premise of unifying various import
mechanisms, but to me that's a secondary goal -- good housekeeping, but not
the problem that the actual web developers (not implementers) are actually
up against today. And, at least personally, I think we should prioritize
developer needs over implementers. That said, I don't think we're actually
that far apart...

> > XHR provides arbitrary resource loading, but it lacks the power to
> > express transport-layer options such as relative request priority
> That is fixed by exposing Request initialisation flags on XHR.

I've seen discussions about exposing this on Fetch, but not XHR. Granted,
one is not far from the other.

> > and dependencies,
> That's fixed by using the proposal in this thread.

We're talking about different "dependencies". I mean transport-layer
dependencies - i.e. if possible, ship bytes for resource A before bytes for
resource B. Again though, if we can express priorities, we should be able
to express (transport) dependencies via the same mechanism, so this is not
a big deal.

> > and it also hides requests from the preload scanner, which is a
> > deal-break for performance.
> That's why the proposal in this thread uses the existing import mechanisms
> to define how the dependencies.

But restricts it to a subset of resource types. Granted, this is not an
issue if you give me a generic way to load any resource, ala rel=preload.

> > (2) We also need a declarative, content-type agnostic primitive to
> > express resource loads, such that the preload scanner is able to pickup
> > and processes these fetches on par with all other resources -- hence my
> > rel=preload suggestion.
> I don't disagree that we need a way to declarative way to import
> non-browser-native resources (like some text file the script uses for
> storing game level data or something). But I don't think we need a
> redundant mechanism to import resource types that already have existing
> import mechanisms. That's not a "primitive", it's just a redundant
> mechanism.
> I went into more detail on this very topic, considering a wide array of
> options, in the big e-mail I sent recently:
> http://lists.w3.org/Archives/Public/public-whatwg-archive/2014Aug/0177.html

It's only redundant insofar as XHR is a redundant mechanism for loading
arbitrary resources. There are cases where fetching an image / stylesheet /
etc, via XHR is both a reasonable and a required step -
{pre,post}processing, and so on. Moving forward, I think the intent is to
explain resource loading via Fetch. I'm asking for a declarative Fetch
that's preloader friendly and has the same expressive capabilities.

> > We can augment img, script, and other elements, with load-settings and
> > other flags, but that still doesn't cover all the necessary cases. For
> > example, how do I fetch a font file
>    http://dev.w3.org/csswg/css-font-loading/
> ...which presumably would have loadSettings exposed.

Sadly, even that requires executing JavaScript and fails the preloader use

> > or an arbitrary JSON payload with app-data, etc?
> XHR, or <link rel=preload>. I assume you're not expecting us to preparse
> the JSON file.

Right, no execution. Just fetch and nothing else: start the request, stick
into the appropriate cache(s) if applicable, and keep the payload inert.

> > Note that I'm looking for declarative syntax that allows me to set
> > arbitrary fetch priorities - e.g. upgrade my JSON payload to high
> > priority because I need it to render content on the screen. This is the
> > part that we *need* to solve.
> rel=preload with the proposal on this thread handles this fine, as far as
> I can tell.

Yes, I think it's close! A few considerations to account for in the
processing model, based on real-world use cases and feedback from the
webperf group:
- https://igrigorik.github.io/resource-hints/#preload
- *https://igrigorik.github.io/resource-hints/#processing

All I'm arguing for here is that the MVP for giving web developers the
power to start solving these problems is rel=preload. Everything else is a
nice to have. As a result, I'd love to uncouple rel=preload from the
rest... Once/if the other mechanisms are ready, rel=preload would just
inherit them as part of coverage of <link>. As I said earlier, I don't
think we're that far apart.


Reply via email to