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 <sjmi...@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 <mrb...@gmail.com> wrote: > >> On Sun, Oct 6, 2013 at 9:38 AM, Dimitri Glazkov <dglaz...@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 >> > >