Jan, thanks for sharing your thought! It clarified my understanding. I think this is rather a symptom of a missing feature, that is an imperative API for HTML Imports, say, System.importDocument(url).
We the spec writers have been thinking about that, but started from declarative API using <link> instead of adding such kind of imperative API for reasons. However for some use cases like dynamic loading, imperative API will fit better. I admit that it is clumsy to add another <link> to document.head just for requesting an import. This is a bit off-topic but let me explain why started with <link>: - It allows us to incorporate with the HTML parser. For example, we can block <script> from running until all imports become ready. - We see there are similar issues in Web platform. It is not only about imports but also about other linked resources. Think about stylesheets for example, or scripts. It'd better to have some uniform-looking way to load them imperatively but we don't yet figure it out. At the same time we need some loading machinery for web components. As a kind of workaround, we add the API with small surface and limited expressiveness so that we cover major use cases without adding unexpected power that is hard to capture in imperative ways. I concern that shadow-based scoping can be such a "unexpected power". Anyway, I created a bug to track this topic [1]. I don't expect quick progress in this direction as we Web Component team in Blink is now focusing on stabilizing it. We're aware of this though. So... Thanks for your patience. We're aware of the problem. Please think it as a symptom of a limitation we're tentatively forcing. [1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=25319 -- morrita On Thu, Apr 10, 2014 at 4:07 PM, Jan Miksovsky <[email protected]> wrote: > Hajime: As I indicated above, the scenario I'm facing is one where a > component wants to dynamically import some content. > > * From at aesthetic perspective, it feels bad for a component to have > non-local effects on the document. > * It also exposes some implementation details in the host DOM that are > better obscured from the component host. I'd prefer for my component users > to generally view my component as a black box that does something useful, > and would rather not have them wonder why their document head suddenly has > unknown <link> tags in it. > * Finally, this limitation was slightly surprising to me, and might be too > others. Given that I can have a static <link> in an imported document, I'd > gotten the impression that I could put a <link> anywhere. > > This does not seems like a significant problem, but I still wanted to > share my experience in case others were similarly confused, and offer it > for your consideration. > > On Thursday, April 10, 2014 2:03:06 PM UTC-7, Hajime Morrita wrote: >> >> >> >> >> On Thu, Apr 10, 2014 at 10:21 AM, Jan Miksovsky <[email protected]> wrote: >> >>> It looks like dynamic HTML imports are now supported in both Canary >>> (natively) and the polyfill. >>> >>> From experimentation, it appears that <link> tags programmatically added >>> to the page's light DOM load as expected. However, links added to a shadow >>> subtree are not handled and have no effect. >>> >>> Can someone please confirm if that analysis is correct? >>> >>> I tried looking through the spec, which talks about links being >>> associated with the document, but it doesn't specifically say that links in >>> shadow DOM are ignored, so I wanted to check. I ask because I have a >>> component that wants to dynamically load another, and it appears to be able >>> to do so in its light DOM but not its shadow. This to some extent cracks >>> the opacity of the component's internal workings, so I'd been hoping to >>> keep the dynamic links completely within the component's shadow. >>> >> >> This is an interesting question. I filed https://crbug.com/362255 for >> tracking this. >> >> Would you mind to explain how you intend to use <link rel=import> in >> Shadow DOM? We could possibly make this work, but I'm not sure if this >> should work. I don't see how it can be useful. In the context of dynamic >> loading, we can just put newly created <link> into document.head, cannot we? >> >> Let's compare it to <link rel=stylesheet>. It works in Shadow DOM, and >> the style is applied to the scope (shadow tree). For imports though, it >> make less sense to bound it to the scope. Although we could imagine a >> scoped import whose styleheets are loaded into the Shadow Tree, its benefit >> isn't clear for me and it will introduce certain complexity to the design. >> >> If it isn't scoped to Shadow DOM, it doesn't make sense to have it in >> Shadow DOM. Other things like <meta>, non-style <link>, <input>, etc. are >> hidden from global document scope when it is in Shadow DOM. The current >> behavior could be explained in this line. >> >> What do you think? >> >> -- >> morrita >> >> >> >> >> >> >>> >>> On Friday, February 7, 2014 8:48:35 AM UTC-8, Eric Bidelman wrote: >>> >>>> Dynamic imports are now supported, but we haven't done a release yet >>>> that includes it. >>>> >>>> +steve and +scott have a few demos they might be able to share. Both >>>> show dynamic/async imports. >>>> >>>> >>>> On Fri, Feb 7, 2014 at 4:29 AM, Matt Bourne <[email protected]> wrote: >>>> >>>>> Hi Eric >>>>> >>>>> It seems there is a similar question on stack exchange >>>>> >>>>> http://stackoverflow.com/questions/21607663/dynamically-load-web- >>>>> components-html-imports/21627702#21627702 >>>>> >>>>> I wonder if one of the devs could given an updated answer. >>>>> >>>>> I understand that we can instantiate our custom elements just like >>>>> normal elements at any time. The question is more around loading the html >>>>> import for the element with all its css and js includes for example using >>>>> ajax then when it's loaded add the polymer element. >>>>> >>>>> Obviously in a heavy single page web app design I only want to load >>>>> the slideshow element (for example) if it's actually needed. In my use >>>>> case >>>>> I want users to be able to choose between many quite rich elements >>>>> (flipbook, map, gallery, slideshow) I only want to load those elements if >>>>> they are used. >>>>> >>>>> Matt >>>>> >>>>> Follow Polymer on Google+: plus.google.com/107187849809354688692 >>>>> --- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "Polymer" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> To view this discussion on the web visit https://groups.google.com/d/ >>>>> msgid/polymer-dev/edcd77c6-013a-4e98-bb36-1ea19ba3affa%40googl >>>>> egroups.com. >>>>> >>>>> For more options, visit https://groups.google.com/groups/opt_out. >>>>> >>>> >>>> Follow Polymer on Google+: plus.google.com/107187849809354688692 >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "Polymer" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To view this discussion on the web visit https://groups.google.com/d/ >>> msgid/polymer-dev/ce563e1c-e264-4df0-8515-28c7ab122b48% >>> 40googlegroups.com<https://groups.google.com/d/msgid/polymer-dev/ce563e1c-e264-4df0-8515-28c7ab122b48%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- morrita Follow Polymer on Google+: plus.google.com/107187849809354688692 --- You received this message because you are subscribed to the Google Groups "Polymer" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/CALzNm5q4v-sDfsKuR%3D5Emm1nm-7wAuBxOwq%3D145tjY5VXXVWmQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
