Re: [components] Isolated Imports and Foreign Custom Elements
On Sun, May 17, 2015 at 1:54 AM, Maciej Stachowiak m...@apple.com 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
On Sat, May 2, 2015 at 12:07 AM, Maciej Stachowiak m...@apple.com 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
(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 link 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 travis.leith...@microsoft.com 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
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 4:35 PM, Domenic Denicola d...@domenic.me 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
On May 1, 2015, at 9:47 AM, Anne van Kesteren ann...@annevk.nl wrote:
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.
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).
iframe id=frame
/iframe
script
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);
/script
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
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. -- https://annevankesteren.nl/
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 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.
--
https://annevankesteren.nl/
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 link 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 travis.leith...@microsoft.com
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-
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
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: link rel=loader space=isolation-name href=http://other-server.example.com/component-library.html; Fits in nicely with ES realms/spaces/worlds/add your definition.
