Re: [webcomponents] Interaction of shadow DOM, imports, base URIs

This is about right. Being able to use url's relative to the import
location makes imports portable, which is highly desireable.

Fwiw, in the king-leonidas example, finding the template element is a
little more complicated than what's shown. The script is inside the
element, which is, in this case, the parentNode of the script.

    <element name="xer-xes">
      <template><img src="icrushu.png"></template>
      <script>
        var template = document.currentScript.parentNode.
querySelector('template');
        ({
          readyCallback: function() {
            this.createShadowRoot().appendChild(template.content.
cloneNode(true));
          }
        });
      </script>
    </element>


On Tue, May 28, 2013 at 11:28 AM, Dimitri Glazkov <dglazkov@chromium.org>wrote:

> This is a really good question. Web developers expressed the need for
> properly resolving URLs pretty much as soon as they heard of HTML
> Imports: https://www.w3.org/Bugs/Public/show_bug.cgi?id=19870.
>
> What they want is for this to Just Work Like Stylesheets (tm). In
> other words, when they define an import "300.html", then in that file,
> they want to use relative URLs to refer to resources:
>
> 300.html:
> <link rel="import" href="spartans/dilios.html">
> <element name="bottomless-pit" extends="textarea">
>    <link rel="stylesheet" href="themes/super-dark.css">
>    <script src="weapons/dory.js"></script>
>    ...
> </element>
>
> Since custom elements are currently completely decoupled from HTML
> Templates and Shadow DOM, instantiating a shadow tree from a template
> that came from an import is the responsibility of the custom element
> author. The code I've seen in the wild is:
>
> <element name="king-leonidas">
> <template><img src="this-is-sparta.png"></template>
> <script>
> var template = document.currentScript.querySelector('template');
> ({
>     readyCallback: function() {
>
> this.createShadowRoot().appendChild(template.content.cloneNode(true));
>     }
> });
> </script>
>
> Here, cloneNode will simply copy attributes, and destroy any
> information about import's URL. and will definitely not give the
> Spartans^H^H^H^H web developers what they are expecting. Unless:
>
> 1) we run import scripts in a separate scripting context that defines
> "document" to mean something different, or somesuch.
>
> 2) we provide some explicit APIs for resolving relative hyperlinks on
> elements coming from one document to another
>
> 3) we add a processing step of some sort to HTML Imports, where we
> resolve hyperlinks at the time of import.
>
> 4) <your idea here>
>
> :DG<
>
>
> On Fri, May 24, 2013 at 10:15 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> > Basic question: what should the base URI be for a node that's part of a
> > shadow tree that comes from some URI that's not the document URI?
> >
> > Making it be the base URI of the resulting ownerDocument is nice and
> simple
> > and involves no spec changes and means that relative URIs to things like
> > stylesheets or images are totally unusable in the shadow DOM if it's
> meant
> > to be included in documents that have different base URIs... and so are
> > absolute ones, really.  This is the behavior Mozilla's XBL has right now,
> > but it's pretty busted, in my opinion.
> >
> > So what do we actually want here?
> >
> > -Boris
> >
> >
>
>