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: PromiseDocument 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?
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25319 On Thu, Apr 16, 2015 at 12:55 AM, Elliott Sprehn espr...@chromium.org 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: PromiseDocument 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=20683hide_resolved=1 On Thu, Apr 16, 2015 at 7:27 AM, Dimitri Glazkov dglaz...@google.com wrote: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25319 On Thu, Apr 16, 2015 at 12:55 AM, Elliott Sprehn espr...@chromium.org 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: PromiseDocument 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?
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 travis.leith...@microsoft.com 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 travis.leith...@microsoft.com 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: PromiseDocument 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: PromiseDocument 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 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: PromiseDocument 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 link rel=import src=... (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
