Re: [webcomponents] HTML Imports

I remember Adam raving about HTML Imports being awesome after he tried
them. Adam, can you provide color? :)

:DG<


On Fri, Oct 18, 2013 at 4:11 PM, Scott Miles <sjmiles@google.com> wrote:

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