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.


>>> (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

Reply via email to