Re: [webcomponents] HTML Imports

>> they'll have to use a closure to capture the document that the template
lives in

Yes, this is true. But stamping of templates tends to be something custom
elements are really good at, so this paritcular use case doesn't come up
very often.

>> Out of curiosity, what have the Polymer guys been using imports for?

1. Bundling resources. Imports can contain or chain to JS, CSS, or
additional HTML imports, so I have access to bundles in silos of
functionality instead of syntax.

2. Obscuring production details. I can import "library.html" and get an
entire dependency without knowing if it's an optimized build file or a
dependency tree of imports.

3. Relocatability. I can import "elements.html" and that package can
reference resources relative to itself.

4. Importing data as markup, where typically it's then the responsibility
of the importer to consume the data, not the import itself.

5. We would like to use imports for preloading images, depending on the
resolution of the 'view-in-import' discussion.

[sidebar] we tend to declare self-organizing custom elements for data and
then load them in imports. For example, many of our library elements has an
associated `metadata.html` file that contains `<x-meta>` elements with
various details. An interested object can make an blank x-meta element to
access the database, and the details are are encapsulated inside the x-meta
implementation.

Scott

On Fri, Oct 18, 2013 at 3:37 PM, Blake Kaplan <mrbkap@gmail.com> wrote:

> On Sun, Oct 6, 2013 at 9:38 AM, Dimitri Glazkov <dglazkov@chromium.org>
> wrote:
> >> So you have <link href=blah.html> in meh.html and blah.html is:
> >> <div id=test></div>
> >> <script> /* how do I get to #test? */ </script>
> > document.currentScript.ownerDocument.querySelector("#test") :)
>
> This only works for code running directly in the script. The current
> setup means that any time an author has something like:
>
> <template id="foo">...</template>
> <script>
> function cloneFoo() { /* get foo and return it. */ }
> </script>
>
> they'll have to use a closure to capture the document that the
> template lives in, which is rather surprising to me. Also, storing the
> document in a global variable is a footgun, because that global
> variable would potentially collide with another import trying to do
> the same thing. ES6 modules would help here, but there a way's off.
>
> > I think the greatest impact here will be on developers. They have to
> start
> > thinking in terms of multiple documents. We should ask Polymer people:
> they
> > wrote a ton of code with Imports now and I bet they have opinions.
>
> Out of curiosity, what have the Polymer guys been using imports for?
> More than just declaring custom elements? I'm worried that we're
> coming up with a very generic feature with odd semantics that only
> make sense for one narrow use-case.
> --
> Blake Kaplan
>