W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2014

Re: Relative URLs in Web Components

From: Anne van Kesteren <annevk@annevk.nl>
Date: Sun, 5 Oct 2014 10:09:13 +0200
Message-ID: <CADnb78jZU_D2PED=XruaFY+7cSDMSjv6HT0GYvAa6MFM5Ch3aw@mail.gmail.com>
To: Scott Miles <sjmiles@google.com>
Cc: Mathias Bynens <mathias@qiwi.be>, WebApps WG <public-webapps@w3.org>, Addy Osmani <addyo@google.com>, Dimitri Glazkov <dglazkov@google.com>, Hajime Morrita <morrita@google.com>, Erik Arvidsson <arv@chromium.org>, Boris Zbarsky <bzbarsky@mit.edu>
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.

Received on Sunday, 5 October 2014 08:09:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:31 UTC