I just wanted to add that this will be a very important feature for applications that wish to cache web components in browser storage (e.g. IndexedDB) or load web components via a WebSocket connection.  It also allows for making changes to web components (say, changing the element name or inserting additional stylesheets) before they get loaded which would be a killer feature.

My Use Case:

Personally, I just need a mechanism that would allow me to load a web component via a WebSocket without requiring a separate GET request.  My application (Gate One) gets embedded into other web pages directly (no iframe) and it loads/synchronizes all of its assets (JS, CSS, and now HTML templates) over a single WebSocket connection.  It caches assets via IndexedDB (with localStorage fallback) and only re-downloads them when a file gets changed on the server.  That asset synchronization works incredibly well:  It's much faster than individual GET requests and more flexible and efficient than concatenation.  However, there's no way for me to take advantage of web components (currently) using that same mechanism.  If I could download a web component over the WebSocket and load it into the page somehow that would solve the problem.

Even if I could provide a data::URI as the 'href' attribute to a link tag that would work.  I'd just create the data::URI from the cached web component on-the-fly so the inefficiency of base64 encoding would be moot.

Rough sketch:

Promise<Document> importDocument(DOMString url);

Different from XHR due to processing of subresources in the context of the current global.

Moved to https://github.com/w3c/webcomponents/issues/141