RE: [Imports] Considering imperative HTML imports?
Hmmm. Well, regardless, this is tracked here: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25319, so I'll add a few comments to that bug. -Original Message- From: Anne van Kesteren [mailto:ann...@annevk.nl] Sent: Thursday, April 16, 2015 12:54 PM To: Travis Leithead Cc: Boris Zbarsky; public-webapps@w3.org Subject: Re: [Imports] Considering imperative HTML imports? On Thu, Apr 16, 2015 at 9:36 PM, Travis Leithead wrote: > Oh! XHR slipped my mind. It would be identical :) (Though perhaps a > tiny-bit easier to use.) Would it? Imports load subresources and execute scripts within the global of the importer. (Forgot what happens to stylesheets.) -- https://annevankesteren.nl/
Re: [Imports] Considering imperative HTML imports?
On Thu, Apr 16, 2015 at 9:36 PM, Travis Leithead wrote: > Oh! XHR slipped my mind. It would be identical :) (Though perhaps a tiny-bit > easier to use.) Would it? Imports load subresources and execute scripts within the global of the importer. (Forgot what happens to stylesheets.) -- https://annevankesteren.nl/
RE: [Imports] Considering imperative HTML imports?
Oh! XHR slipped my mind. It would be identical :) (Though perhaps a tiny-bit easier to use.) -Original Message- From: Boris Zbarsky [mailto:bzbar...@mit.edu] Sent: Thursday, April 16, 2015 11:30 AM To: public-webapps@w3.org Subject: Re: [Imports] Considering imperative HTML imports? On 4/16/15 12:37 AM, Travis Leithead wrote: > Was an imperative form of HTML imports already considered? E.g., the > following springs to mind: > >Promise importDocument(DOMString url); How is this different from a promise-ified version of XHR, exactly? (Not that there's anything wrong with that; just trying to understand the proposal.) -Boris
Re: [Imports] Considering imperative HTML imports?
On 4/16/15 12:37 AM, Travis Leithead wrote: Was an imperative form of HTML imports already considered? E.g., the following springs to mind: Promise importDocument(DOMString url); How is this different from a promise-ified version of XHR, exactly? (Not that there's anything wrong with that; just trying to understand the proposal.) -Boris
Re: [Imports] Considering imperative HTML imports?
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25319 On Thu, Apr 16, 2015 at 12:55 AM, Elliott Sprehn wrote: > > > On Wed, Apr 15, 2015 at 9:37 PM, Travis Leithead < > travis.leith...@microsoft.com> wrote: > >> Was an imperative form of HTML imports already considered? E.g., the >> following springs to mind: >> >> Promise importDocument(DOMString url); >> >> >> >> I was thinking about Worker’s importScripts(DOMString… urls), and the >> above seems like a nice related corollary. >> > > We did consider this, I think there's still a proposal for an imperative > document.import(url) => Promise API. The major advantage of the declarative > approach is that the browser can fetch the entire import tree and even > start tokenizing on a background thread without ever running any script. > > - E >
Re: [Imports] Considering imperative HTML imports?
Imports bug tree: https://www.w3.org/Bugs/Public/showdependencytree.cgi?id=20683&hide_resolved=1 On Thu, Apr 16, 2015 at 7:27 AM, Dimitri Glazkov wrote: > https://www.w3.org/Bugs/Public/show_bug.cgi?id=25319 > > On Thu, Apr 16, 2015 at 12:55 AM, Elliott Sprehn > wrote: > >> >> >> On Wed, Apr 15, 2015 at 9:37 PM, Travis Leithead < >> travis.leith...@microsoft.com> wrote: >> >>> Was an imperative form of HTML imports already considered? E.g., the >>> following springs to mind: >>> >>> Promise importDocument(DOMString url); >>> >>> >>> >>> I was thinking about Worker’s importScripts(DOMString… urls), and the >>> above seems like a nice related corollary. >>> >> >> We did consider this, I think there's still a proposal for an imperative >> document.import(url) => Promise API. The major advantage of the declarative >> approach is that the browser can fetch the entire import tree and even >> start tokenizing on a background thread without ever running any script. >> >> - E >> > >
Re: [Imports] Considering imperative HTML imports?
On Wed, Apr 15, 2015 at 9:37 PM, Travis Leithead < travis.leith...@microsoft.com> wrote: > Was an imperative form of HTML imports already considered? E.g., the > following springs to mind: > > Promise importDocument(DOMString url); > > > > I was thinking about Worker’s importScripts(DOMString… urls), and the > above seems like a nice related corollary. > We did consider this, I think there's still a proposal for an imperative document.import(url) => Promise API. The major advantage of the declarative approach is that the browser can fetch the entire import tree and even start tokenizing on a background thread without ever running any script. - E
Re: [Imports] Considering imperative HTML imports?
On Thu, Apr 16, 2015 at 1:37 PM, Travis Leithead < travis.leith...@microsoft.com> wrote: > Was an imperative form of HTML imports already considered? E.g., the > following springs to mind: > > Promise importDocument(DOMString url); > > > > I was thinking about Worker’s importScripts(DOMString… urls), and the > above seems like a nice related corollary. > One big difference, I'm assuming, is whether it's asynchronous. Returning a Promise kind of implies that importDocument may be/is asynchronous. The trend seems to be away from adding synchronous APIs, but then you can't express (ie no 'async') using this API. I think the declarative, script-blocking element is more palatable than a synchronous method because the UA can process it when there's no user script running. Dominic
