- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Sat, 4 Oct 2014 15:27:29 +0200
- 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. -- https://annevankesteren.nl/
Received on Saturday, 4 October 2014 13:27:56 UTC