W3C home > Mailing lists > Public > whatwg@whatwg.org > September 2014

Re: [whatwg] Preloading and deferred loading of scripts and other resources

From: Ian Hickson <ian@hixie.ch>
Date: Tue, 2 Sep 2014 15:32:11 +0000 (UTC)
To: Yoav Weiss <yoav@yoav.ws>
Message-ID: <alpine.DEB.2.00.1409021509490.2532@ps20323.dreamhostps.com>
Cc: "whatwg@whatwg.org" <whatwg@whatwg.org>
On Tue, 2 Sep 2014, Yoav Weiss wrote:
> On Sat, Aug 23, 2014 at 2:44 AM, Ian Hickson <ian@hixie.ch> wrote:
> [snip]
> > 
> >    load-settings=""    A JSON-encoded dictionary to pass to the Request
> >                        constructor.
>
> I'm not a big fan of JSON attributes for this purpose

Nobody is, as far as I know. It's just the least bad option suggested so 
far. Some of the alternatives we've discussed include:

 - a whole farm of content attributes
     -- pro: no mixed markup languages (JSON+HTML)
     -- con: lots of attributes instead
     -- con: leads to a situation where we have entirely different APIs
             in different cases (content attribute farm for HTML elements,
             some other API for non-elements)
     -- con: hugely increases (potentially in an unbounded fashion) the
             number of allowed attributes on many elements
     -- con: would have non-trivial document conformance rules (the
             attributes are probably interrelated, especially e.g. the
             ones for setting HTTP headers)
     -- con: ends up being really ugly and hard to use (how do you
             set the second HTTP header? It's not intuitive. How do you
             remove the first while leaving the second?)
     -- con: ends up even uglier if we ever need two sets on one element
             (e.g. one for poster="" and one for src="" on <video>,
             or one for each URL in a srcset="")

 - a new microsyntax, maybe CSS-like
     -- pro: can be optimised for the use case
     -- pro: can easily be given a dedicated API
     -- con: other than skipping the outer braces, it's not clear how
             much different it would end up being than JSON
     -- con: still results in mixed markup languages
     -- con: requires a custom parser
     -- con: language would have to be non-trivial since it has to
             include substrings (and escaping in those strings) and
             nested structures (e.g. for setting headers)

 - JSON
     -- pro: some extensibilty (so long as we just want a tree structure 
             of strings and numbers, anyway)
     -- pro: existing standard syntax with off-the-shelf parsers
     -- pro: easily placed on other objects
     -- pro: easily duplicated if an element needs multiple Requests
     -- pro: can easily be given a dedicated API
     -- con: verbose
     -- con: mixed markup languages
     -- con: requires a non-trivial parser on the preloader thread


> What's the use-case that requires a Request constructor?

Each Fetch has a Request. So assuming we want to "explain" the Web 
platform in terms of Fetch, we need a corresponding Request for each 
Fetch. The Request lets you control HTTP2 priorities and so forth.


> If so, maybe we can expose that only through JS initially, see what 
> people use it for, and if it makes sense add it to markup later on?

Well the Request object is only exposed through JS. But the Request 
object's construction parameters have to be exposed through markup because 
for many elements there's no time between the creation of the element and 
the creation of the Request passed to the Fetch.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 2 September 2014 15:32:38 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:30 UTC