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

On Nov 19, 2013 2:22 AM, "Ryosuke Niwa" <rniwa@apple.com> wrote:
>
>
> 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?
>

I think james burke purposes something to that effect
https://gist.github.com/jrburke/7455354#comment-949905 (relevant bit is in
reply to me, comment #4 if i understand the question)