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: Sat, 4 Oct 2014 15:27:29 +0200
Message-ID: <CADnb78jEhLq1jFP=HMms0OrMNUcpSh22H9CFdMEAUN0evhs0ww@mail.gmail.com>
To: Mathias Bynens <mathias@qiwi.be>
Cc: 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 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.

Received on Saturday, 4 October 2014 13:27:56 UTC

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