[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 #18 from Morrita Hajime <morrita@google.com> ---

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.

In an IDL form,

---

partial interface DocumentFragmentRenderable {
  readonly attribute String baseURL;
  void render(DocumentFragmentRenderable);
};

DocumentFragment implements DocumentFragmentRenderable;
// FIXME: Seems to aggressive?
// Element implements DocumentFragmentRenderable; 

---

This approach has some pros:

- Component authors no longer need to take care of base URL.
  It works automatically once they use render().
- baseURI can be read-only thus less error prone (in Blink!)
- The definition is orthogonal from other Shadow bits and easily move to HTML
or other standard.
  Even HTML Imports can host it :-) XHR users can get benefit from it as well.

One cons is that this is not useful without ShadowRoot.
We can possibly let Element implement DocumentFragmentRenderable,
but I'm not sure if it worth doing since implementation will be harder.

What do you think?
Any suggestions are welcome. 
Well, the name render() could be better first of all :-)

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

Received on Thursday, 22 August 2013 08:27:18 UTC