If you take a look at [1], we extend the custom elements registration mechanism 
so that the constructor is still available in the hosting global, yet the 
implementation is defined in the isolated environment.

An approach to solving this might address another concern I have...

I've been thinking about the way that the APIs are created with my proposal and 
the design wherein you have an explicit API to create the API signature on the 
prototype (and instances) leaves a lot of room for potential issues. For 
* Nothing requires the isolated component to create any APIs initially (leaving 
the custom element without any API until some random later time of the isolated 
component's choosing).
* There is no way to know when the isolated component's APIs creation is "done"
* The isolated component can remove APIs at any time; this is not a pattern 
that user agents ever make use of and there's no use case for it--doesn't seem 
appropriate to give this power to the isolated component

To address these problems, if you change the model to work more like what 
Maciej proposed where you can have N number of custom elements defined by one 
global, then in the creation of a particular custom element (specifically it's 
prototype) you can specify what APIs should be defined on it in one shot 
(creation time) and don't provide any other way to do it. This naturally 
satisfies my above concerns. So, a rough sketch might be something like:

   void exportElement(DOMString customElementName, PropDescDictionary 

usage example:

document.exportElement("element-name", {
    api1: { enumerable: true, value: function() { return "hello, from the 
isolated component"; }},
    api2: { /* etc... */ }
// returns void (or throws is "element-name" is already defined/exported?)

Once you divorce the isolated component in this way, you rightly point out the 
problem of how to get the custom element's constructor function exported 
outside of the isolated environment. One possible approach to solve this allows 
the host to ask for the custom element constructor function explicitly. Rough 

    Function importConstructor("element-name");

usage example:

window.MyElementName = document.importConstructor("element-name");
// now new MyElementName(); returns an instance of "element-name" element

You can imagine this might be useful for any custom element (either those 
exported as shown above, or those defined using registerElement -- the 
non-isolated custom elements).

Just some food for thought.


-----Original Message-----
From: Anne van Kesteren [mailto:ann...@annevk.nl] 
Sent: Friday, May 1, 2015 9:48 AM
To: Maciej Stachowiak
Cc: WebApps WG
Subject: Re: [components] Isolated Imports and Foreign Custom Elements

On Thu, Apr 23, 2015 at 8:58 PM, Maciej Stachowiak <m...@apple.com> wrote:
> I wrote up a proposal (with input and advice from Ryosuke Niwa) on a 
> possible way to extend Web Components to support fully isolated components:
> https://github.com/w3c/webcomponents/wiki/Isolated-Imports-Proposal
> I welcome comments on whether this approach makes sense.

I don't get the bit where you create a node in one global, but run its 
constructor in another. That seems rather Frankenstein-esque. Would love to see 
more details overall, as the direction this is going in certainly seems like 
the kind of thing we want. Allowing a dozen Facebook Like buttons to appear on 
a page using only one additional global.


Reply via email to