[Bug 19870] [Imports]: Ensure import resources are loaded relative to location of import definition

https://www.w3.org/Bugs/Public/show_bug.cgi?id=19870

--- Comment #19 from Elliott Sprehn <esprehn@gmail.com> ---
(In reply to comment #18)
> Node.baseDocument seems too powerful for me,
> but I agree that it'd be great if there is a straightforward way to
> retain the origin (or base) of imported fragments.
> 
> For me, DocumentFragment.baseURL, thus ShadowRoot.baseURL, feels right.
> DocumentFragment or ShadowRoot represents a kind of scope and boundary,
> which could have its own "scoped" base URL.
> The default value of the baseURL is one of the owner document.
> 
> The challenge here is that there is no way to "pass" the baseURL one from
> another.
> If you use appendChild(), ownerDocuments of new children are overwritten.
> We want to retain it, or the URL of it, somehow.
> 
> I think we could add new ShadowRoot (or DocumentFragment) API to do this
> "baseURI-preserving" appendChild() alternative, say,
> ShadowRoot::render(documentFragment).
> 
> This hypothesis render() API
> 
> - removes existing ShadowRoot children
> - clones the document fragment children and inserts it to the ShadowRoot, and
> - replaces ShadowRoot's baseURL with one of DocumentFragment.
> 
> 

This is the wrong abstraction level, we shouldn't be adding new DOM mutation
methods (you've just reinvented innerHTML = ''; appendChild(fragment) on
ShadowRoot) to support this.

We could expose something like document.currentImport just like
document.currentScript and Import can have a resolveURL() method on it where
you could go fixup your resource urls when the component is stamped.

I don't like adding magical behavior here, even at the root level, it seems
very confusing because now:

var img = new Image();
img.src = 'foo.png'; // load actually started here.
appendChild(img); // now the url is different, we start loading a different
thing.

also if you remove an img from one shadow root and stick it into another all
the urls are going to change.

I think we should be explicit and just expose a URL resolver thing on imports
and then let applications setup the necessary abstractions (ex. MDV can do the
url replacing for you if needed).

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Thursday, 22 August 2013 18:22:36 UTC