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

There seems to be some idea that HTML imports are supposed to do
everything. The primary use case for HTML imports is a way to import DOM
trees. Since HTML already have ways to embed CSS and script, HTML imports
can act as a container format. But do not let perfect be the enemy of good.
Lets not try to fix the issues of CSS and JS by make HTLM import try to
solve all of these at once.

To answer a few points.

You should be able to use <module>/<script type=module> inside an HTML
import. It will do the "encapsulation" (top level vars are not global
vars). Lets focus on solving this problem by itself. It is orthogonal to
importing HTML.

Different global scope. Modules do not provide a new global scope by
default. Why should script/module inside an HTML import do that? That seems
inconsistent. Also, having different Array/Function/Node etc causes issues
because code often expect the prototype to not be different.


James Burke also brought up the issue related to naming on the import side.
That works well for JS because the name that the importer choses does not
change the interface of the object [*]. However, the name of an element is
one of the most important parts of its interface. What happens when you
have multiple HTLM imports that imports the same custom element but with
different names and then these elements are moved between the documents?
Are we going to rename them to ensure that my x-foo is always an XFoo?



On Tue, Nov 19, 2013 at 5:13 AM, Brian Kardell <bkardell@gmail.com> wrote:

>
> 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)
>



-- 
erik