Re: [HTML Imports]: what scope to run in

On Nov 19, 2013, at 2:10 PM, Dimitri Glazkov <dglazkov@chromium.org> wrote:

> On Mon, Nov 18, 2013 at 8:26 PM, Ryosuke Niwa <rniwa@apple.com> wrote:
> We share the concern Jonas expressed here as I've repeatedly mentioned on another threads.
> 
> On Nov 18, 2013, at 4:14 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>> This has several downsides:
>> * Libraries can easily collide with each other by trying to insert
>> themselves into the global using the same property name.
>> * It means that the library is forced to hardcode the property name
>> that it's accessed through, rather allowing the page importing the
>> library to control this.
>> * It makes it harder for the library to expose multiple entry points
>> since it multiplies the problems above.
>> * It means that the library is more fragile since it doesn't know what
>> the global object that it runs in looks like. I.e. it can't depend on
>> the global object having or not having any particular properties.
> 
> Or for that matter, prototypes of any builtin type such as Array.
> 
>> * Internal functions that the library does not want to expose require
>> ugly anonymous-function tricks to create a hidden scope.
> 
> IMO, this is the biggest problem.
> 
>> Many platforms, including Node.js and ES6 introduces modules as a way
>> to address these problems.
> 
> Indeed.
> 
>> At the very least, I would like to see a way to write your
>> HTML-importable document as a module. So that it runs in a separate
>> global and that the caller can access exported symbols and grab the
>> ones that it wants.
>> 
>> Though I would even be interested in having that be the default way of
>> accessing HTML imports.
> 
> Yes!  I support that.
> 
>> I don't know exactly what the syntax would be. I could imagine something like
>> 
>> In markup:
>> <link rel=import href="..." id="mylib">
>> 
>> Once imported, in script:
>> new $('mylib').import.MyCommentElement;
>> $('mylib').import.doStuff(12);
>> 
>> or
>> 
>> In markup:
>> <link rel=import href="..." id="mylib" import="MyCommentElement doStuff">
>> 
>> Once imported, in script:
>> new MyCommentElement;
>> doStuff(12);
> 
> 
> How about this?
> 
> In the host document:
> <link ref=import href="foo.js" import="foo1 foo2">
> <script>
> foo1.bar();
> foo2();
> </script>
> 
> In foo.js:
> module foo1 {
> export function bar() {}
> }
> function foo2() {}
> 
> I think you just invented the <module> element: https://github.com/jorendorff/js-loaders/blob/master/rationale.md#examples

Putting the backward compatibility / fallback behavior concern with respect to the HTML parsing algorithm aside, the current proposal appears to only support js files.  Are you proposing to extend it so that it can also load HTML documents just like link[rel=import] does?

> In fact, the list of concerns that Jonas listed is specifically addressed by modules. So, my thinking is that why don't we leave imports alone and let the modules solve these problems? HTML Imports is a higher-layer vehicle -- it simply allows you to build a dependency tree out of HTML files. In turn, HTML Imports use modules to apply proper scoping of scripts.

How does module work with HTML imports?  As far as I read the spec, the imported document can define (and only define) whatever module it wants to declare on the global scope of the host document.


On Nov 19, 2013, at 3:53 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Mon, Nov 18, 2013 at 9:10 PM, Dimitri Glazkov <dglazkov@chromium.org> wrote:
>> In fact, the list of concerns that Jonas listed is specifically addressed by
>> modules. So, my thinking is that why don't we leave imports alone and let
>> the modules solve these problems? HTML Imports is a higher-layer vehicle --
>> it simply allows you to build a dependency tree out of HTML files. In turn,
>> HTML Imports use modules to apply proper scoping of scripts. And everybody
>> is happy :)
> 
> Except as the specification is currently written, I don't see a way to
> do that. I.e. the only way the imported page can "communicate" back to
> the main page is by interacting with its global.


Same here.

- R. Niwa