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 case. > > 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 <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. ig