Re: [components] Isolated Imports and Foreign Custom Elements
On Sun, May 17, 2015 at 1:54 AM, Maciej Stachowiak wrote: > > (Replying to slightly old thread.) > > > > > Another thing that might be nice is that if these elements are that > > much isolated, perhaps we can consider allowing them to be renamed > > them as well, similar to what module systems allow you to do. > > An earlier version of my proposal had support for arbitrary renaming at > import time. However, Ryosuke convinced me that the syntax was confusing, > and that importing with a different prefix would always be sufficient to > resolve namespace collisions. That’s what the proposed prefix attribute is > for. Thus, you can import "abc-button" as "xyz-button" but arbitrary other > renames are not supported. This relies on the requirement that custom > element names must contain a hyphen, and the convention that the bit before > the hyphen is often treated as a namespace prefix. If there are good use > cases for arbitrary renames, it’s probably not too hard to support them. > (replying to a now even more older thread) FWIW, I like both of the approaches and would like to figure out a way to move forward with these. I personally slightly prefer the isolated imports approach a bit better, because some of the sugar in it (like prefix-renaming) is actually something the non-isolated imports might use as well. :DG<
Re: [components] Isolated Imports and Foreign Custom Elements
(Replying to slightly old thread.) > > Another thing that might be nice is that if these elements are that > much isolated, perhaps we can consider allowing them to be renamed > them as well, similar to what module systems allow you to do. An earlier version of my proposal had support for arbitrary renaming at import time. However, Ryosuke convinced me that the syntax was confusing, and that importing with a different prefix would always be sufficient to resolve namespace collisions. That’s what the proposed prefix attribute is for. Thus, you can import "abc-button" as "xyz-button" but arbitrary other renames are not supported. This relies on the requirement that custom element names must contain a hyphen, and the convention that the bit before the hyphen is often treated as a namespace prefix. If there are good use cases for arbitrary renames, it’s probably not too hard to support them. Regards, Maciej
RE: [components] Isolated Imports and Foreign Custom Elements
>> (1) All of the parameters to registerElement() should really be provided by >> the cross-origin element itself. It makes no sense for prototype and extends >> to come from the hosting environment. It does makes sense for the cross-origin component to own the element name and extends that it defines, as this name may be important for its documentation and potentially sub-classing behavior. So +1 to that, though when handing that naming control to the host, the host can independently manage naming collisions. I'm just mentioning that--not suggesting that we should design for that particular use case. On the API control: One other approach I considered was to use ES6 proxies in some way, because the drawback with the property descriptor approach (if you consider it a drawback) is that you can't create cross-origin components whose elements act like DOM Collections (e.g. the behavior of 'window' or 'form' which have named property/indexed property getters). Perhaps these 'feature' of the current DOM should be discouraged in component creation, but if not, you'd need something with the flexibility of ES6 Proxies. I stuck with property descriptors in the proposal because Proxy use seems like overkill for the simple API definition scenarios (in other words, for a simple property, I don't want to have to define the proxy handler methods: has, get, deleteProperty, enumerate, ownKeys, etc. I'm not sure to what extent your two-way membrane proxy would handle this case... -Original Message- From: Maciej Stachowiak [mailto:m...@apple.com] Sent: Friday, May 1, 2015 2:57 PM To: Travis Leithead Cc: Anne van Kesteren; WebApps WG Subject: Re: [components] Isolated Imports and Foreign Custom Elements Your proposal seems conceptually very similar to mine. I guess that’s a good sign! It seems the biggest difference is the foreign registration hook - whether it’s done at class registration time (registerElement) or done at import time. The reasons I did not go with class registration time are: (1) All of the parameters to registerElement() should really be provided by the cross-origin element itself. It makes no sense for prototype and extends to come from the hosting environment. (2) You need to define an elaborate protocol for the outside origin to do the “inside” of the registration operation. (3) At least in the obvious way to do it, you need one external document per custom element type. (4) It’s less aligned with regular HTML imports, which are the non-cross-origin non-isolated tool for importing a bunch of element definitions. (5) Documents referenced by can be preloaded aggressively, but loads initiated from a script parameter cannot. On these grounds, I think doing the loading at import time, and explicit import/export lists, are a simpler and cleaner solution. It sounds like you agree with some of the reasons below. I guess the other big difference is that your approach allows customizing what API is exposed, rather than proxying everything defined by the custom element instance in its own world. That is intriguing to me, but I’m not sure it’s necessary. The custom element can have truly private methods and slots by using ES6 symbols, and my proposed rule to do extended structured cloning on parameters and returns limits the risk of exposing everything. But I agree with you that if we need fine-grained API control, it’s better to do it with property descriptor-like structures than in a fully programmatic way. Regards, Maciej > On May 1, 2015, at 10:46 AM, Travis Leithead > wrote: > > 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 example: > * 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 > globa
Re: [components] Isolated Imports and Foreign Custom Elements
On Sat, May 2, 2015 at 12:07 AM, Maciej Stachowiak wrote: > It’s already possible to run a constructor from another global object in the > non-cross-origin case. Okay, that makes more sense. I first read it as a suggestion we'd construct a node using a same-global constructor and then also run the foreign-global constructor and it didn't really compute. > I think it may be necessary to do an experimental implementation to work out > all the details of how the two-way isolation works. I have the feeling there's some overlap with compartments: http://andreasgal.com/2010/10/13/compartments/ Though I guess non-Gecko implementations still want to avoid going there. Another thing that might be nice is that if these elements are that much isolated, perhaps we can consider allowing them to be renamed them as well, similar to what module systems allow you to do. -- https://annevankesteren.nl/
Re: [components] Isolated Imports and Foreign Custom Elements
On May 1, 2015, at 4:35 PM, Domenic Denicola wrote: >> alert(weirdArray.__proto__ == localArray.__proto__) > > This alerts false in IE, Firefox, and Chrome. > That is what I'd expect it to do. (It does the same in Safari). I guess I didn't explain why I put this line in, so for clarity: this line demonstrates that the instance created was not of the local browsing context's Array, but rather of the distinct Array from the other frame. Which shows that there is a well-defined meaning to creating instances of constructors from another global object. Apologies if this was too subtle. Regards, Maciej
RE: [components] Isolated Imports and Foreign Custom Elements
> alert(weirdArray.__proto__ == localArray.__proto__) This alerts false in IE, Firefox, and Chrome.
Re: [components] Isolated Imports and Foreign Custom Elements
> On May 1, 2015, at 9:47 AM, Anne van Kesteren wrote: > > On Thu, Apr 23, 2015 at 8:58 PM, Maciej Stachowiak 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. It’s already possible to run a constructor from another global object in the non-cross-origin case. Simple example below (it uses a built-in type as the example, but it could work just as easily with a custom defined prototype-based constructor or ES6 class constructor). function doIt() { window.ForeignArray = document.getElementById("frame").contentWindow.Array; var localArray = new Array(); var weirdArray = new ForeignArray(); alert(weirdArray.__proto__ == localArray.__proto__); } window.addEventListener("load", doIt); My proposal suggest something similar, except everything is wrapped with translating proxies at the origin boundary. I think it may be necessary to do an experimental implementation to work out all the details of how the two-way isolation works. > 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. Yes, that’s the goal. Regards, Maciej
Re: [components] Isolated Imports and Foreign Custom Elements
Your proposal seems conceptually very similar to mine. I guess that’s a good sign! It seems the biggest difference is the foreign registration hook - whether it’s done at class registration time (registerElement) or done at import time. The reasons I did not go with class registration time are: (1) All of the parameters to registerElement() should really be provided by the cross-origin element itself. It makes no sense for prototype and extends to come from the hosting environment. (2) You need to define an elaborate protocol for the outside origin to do the “inside” of the registration operation. (3) At least in the obvious way to do it, you need one external document per custom element type. (4) It’s less aligned with regular HTML imports, which are the non-cross-origin non-isolated tool for importing a bunch of element definitions. (5) Documents referenced by can be preloaded aggressively, but loads initiated from a script parameter cannot. On these grounds, I think doing the loading at import time, and explicit import/export lists, are a simpler and cleaner solution. It sounds like you agree with some of the reasons below. I guess the other big difference is that your approach allows customizing what API is exposed, rather than proxying everything defined by the custom element instance in its own world. That is intriguing to me, but I’m not sure it’s necessary. The custom element can have truly private methods and slots by using ES6 symbols, and my proposed rule to do extended structured cloning on parameters and returns limits the risk of exposing everything. But I agree with you that if we need fine-grained API control, it’s better to do it with property descriptor-like structures than in a fully programmatic way. Regards, Maciej > On May 1, 2015, at 10:46 AM, Travis Leithead > wrote: > > 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 example: > * 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 > definitions); > > usage example: > > ```js > 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 idea: > >Function importConstructor("element-name"); > > usage example: > > ```js > 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. > > [1] > https://github.com/w3c/webcomponents/wiki/Cross-Origin-Custom-Elements:-Concept-and-Proposal > > -Original Message- >
RE: [components] Isolated Imports and Foreign Custom Elements
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 example: * 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 definitions); usage example: ```js 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 idea: Function importConstructor("element-name"); usage example: ```js 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. [1] https://github.com/w3c/webcomponents/wiki/Cross-Origin-Custom-Elements:-Concept-and-Proposal -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 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. -- https://annevankesteren.nl/
Re: [components] Isolated Imports and Foreign Custom Elements
On Thu, Apr 23, 2015 at 8:58 PM, Maciej Stachowiak 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. -- https://annevankesteren.nl/
RE: [components] Isolated Imports and Foreign Custom Elements
On Thu Apr 23 02:58 PM, Maciej Stachowiak wrote: > > https://github.com/w3c/webcomponents/wiki/Isolated-Imports-Proposal > > I welcome comments on whether this approach makes sense. Security rules are unclear but love this approach https://lists.w3.org/Archives/Public/public-webapps/2014JulSep/0024.html (2) Ability to have the script associated with the component run in a separate “world” An alternative syntax: http://other-server.example.com/component-library.html";> Fits in nicely with ES realms/spaces/worlds/add your definition.