On Sep 8, 2014, at 10:54 PM, Ilya Grigorik <igrigo...@gmail.com> wrote:
> 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. What problem(s) are those developers going to solve with such a low level API other than the use cases A through Z listed here? > 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… What are problems Web developers actually up against today? Not having a low-level network API, on its own, isn’t a problem. Please give us a concrete real world use case for which the proposed API doesn’t work. >>> 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. Right. >>> (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. I think rel=preload gives us a declarative preloader friendly syntax for Fetch. >>> 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. Which values of loadpolicy content attribute are you proposing to support? - R. Niwa
