Re: Relative URLs in Web Components

> The URL is parsed again? That seems like something that should not
> happen. Are you copying the node perhaps?

There is no explicit copying, but I don't know if there is something
implicit happening when the element goes trans-document.

Sample code (assume index.html that imports import/import.html).

<!-- import/import.html -->

<img src="beaker.jpg">

<script>

  // node above in this import
  var img = document.currentScript.ownerDocument.querySelector('img');

  console.log(img.src, img.getAttribute('src'));
  // > 'import/beaker.jpg', 'beaker.jpg'

  // do this to freeze the src
  //img.src = img.src;

  // move node to window.document
  document.body.appendChild(img);

  console.log(img.src, img.getAttribute('src'));
  // > 'beaker.jpg', 'beaker.jpg'

  // img.src is 404

</script>


Live version at http://sjmiles.github.io/import-beaker/ (needs Chrome for
HTMLImports).

> neither of these solves the case for a script in an
> imported document
> [that would] require usage of the URL API to properly resolve base URLs
first which
> not likely something you would think about.

Very true. For Polymer we took this hit and gave every element a
`resolvePath` fixup method. As you say, you'd never consider this without
documentation, and some lose a toe. Otoh, it may be a survivable
compromise. Anecdotally, it hasn't come up with heinous frequency, and the
solution seems to appease those who find it.

> The lack of encapsulation is major hassle.

I'm not sure what you mean, can you elaborate? If this is the root cause,
maybe we attack it there.

Thanks,
Scott

On Sun, Oct 5, 2014 at 1:09 AM, Anne van Kesteren <annevk@annevk.nl> wrote:

> On Sat, Oct 4, 2014 at 7:00 PM, Scott Miles <sjmiles@google.com> wrote:
> > An issue is that a relative URL is only correct as long as the `img` (for
> > example) is owned by the import. If you migrate the element to the main
> > document, the path is now relative to the wrong base, and users are
> > confused. One can do `img.src = img.src;` before migrating the node, and
> > that will freeze the resolved path, but this is somewhat arcane.
>
> The URL is parsed again? That seems like something that should not
> happen. Are you copying the node perhaps?
>
>
> > As Anne points out, this issue is worse when you start using templates.
> The
> > `img` in the template isn't live and never has a resolved `src` property.
> >
> > If the use cases are:
> >
> > - migrating a sub-tree from an import to another document
> > - migrating a sub-tree from a template to another document
> >
> > In both cases, users frequently want migrated elements to retain a base
> URL
> > from the original document (except when they don't, for example when they
> > are using anchor links, href="#foo" =/).
>
> This problem stems directly from components not having proper
> encapsulation.
>
> There's two ways this can be solved and neither seems particularly
> attractive:
>
> 1) We parse imported documents in a special way. Either having
> elements parse their URLs at an earlier point or actually storing the
> parsed URL in the tree. Note that this would also require a special
> parsing mode for CSS and that we would have to parse CSS (not apply)
> even in <template>.
>
> 2) Rather than document-scoped, we make base URLs node-scoped and
> provide a way to move a node around while preserving its base URL
> (node because at least Element and DocumentFragment would need this).
> The implications here at that URL parsing for every node becomes a
> more expensive operation due to tree traversal.
>
> And again, neither of these solves the case for a script in an
> imported document setting innerHTML, or fetching something. They would
> require usage of the URL API to properly resolve base URLs first which
> is not likely something you would think about.
>
> The lack of encapsulation is major hassle.
>
>
> --
> https://annevankesteren.nl/
>