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

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() {}


On Nov 18, 2013, at 4:52 PM, Scott Miles <sjmiles@google.com> wrote:
> The HTMLImports we've been working with so far is not primarily about JS, it's about HTML.
> There are already various ways to modularize JS, including requirejs, other libs, and of course, ES6 modules.
> Isolation of globals has definite use cases, but it also has costs, and is more intervention than is required for first-party use cases. It's been argued (convincingly, from my perspective) that isolation can be successfully implemented via a separate opt-in mechanism.

I understand your perspective but has anyone outside Google shared the same opinion?  If so, could you give us pointers (URL to a post, etc..)?

> I suggest that keeping HTMLImports as primitive as possible is a virtue on almost all fronts.


Running scripts in the host document while keeping the rest in a separate document isn't exactly simple IMO.  If we kept a separate document & window object, then HTML imports behave more like an display:none iframe with automatic JS value binding.

There is a huge advantage in matching iframe's behavior here.

- R. Niwa