Re: Relative URLs in Web Components

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.

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" =/).

I've hand-waved definitions of 'migrating', 'base URL', and 'original
document', but I'm only trying to frame the (as Anne said, hard) problem.

Scott

On Sat, Oct 4, 2014 at 6:27 AM, Anne van Kesteren <annevk@annevk.nl> wrote:

> On Thu, Oct 2, 2014 at 3:09 PM, Anne van Kesteren <annevk@annevk.nl>
> wrote:
> > This is a hard problem:
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20976#c8
>
> I saw you commented on the bug, but I prefer keeping that bug focused
> on several other problems around base URLs so let's continue here. You
> gave this example:
>
> # Consider this document, located at
> # https://example.com/some-component/import-me.html:
> #
> #   <img src=foo>
> #
> # It would be nice if the import process would *somehow*
> # turn that into…
> #
> #   <img src=https://example.com/some-component/foo>
> #
> # …before inserting it into the parent document.
>
> As far as I can tell this particular example should already work. The
> base URL for that <img> element will be that of the document it is in,
> which is the import (at least per the algorithms in HTML Imports).
> What makes you think it would not work?
>
> The problem is with <template> as that isolates elements which will
> therefore not be processed and their associated URLs will therefore
> not parse, etc. Now we could perhaps add a special
> in-<template>-processing model for all elements that can have one or
> more associated URLs, or something along those lines, but it's not
> clear that's worth it.
>
>
> --
> https://annevankesteren.nl/
>
>