Explain intersection semantics with ShadowRealm

[caridy]

The readme explicitly defines this proposal as orthogonal to ShadowRealm rather than complementary. To that instance, it is not clear if the meta/header script is going to be evaluated inside a ShadowRealm when created since its s running on the same process and bound to the root settings object. I suspect the answer is NO, it is not going to get executed inside a ShadowRealm. If that's the case, please, document it to avoid confusion.

[weizman]

Will do, how do you recommend I approach this?
For documentation purposes, what is the definition that sets realms with sync access to the top apart from those that do not?
I used to think "same agent" or "same origin", but ShadowRealm cancels those - is there a better definition that sets them apart?

[caridy]

Given the current state of affairs (and the work done by @ptomato):

w3ctag/design-principles#509

APIs should be purely computational. That is, they do not perform I/O and do not affect the state of the user agent or the user's device.

This means three things:

1. that creating a script that is applicable to both, window and shadowRealm instances is going to be tricky for developers. A lot of feature detection... which might result on them only focusing on window, and keeping the capability available via new ShadowRealm()
2. it is very likely that none of the stuff in a ShadowRealm are going to be problematic, because they don't grant you authority of any kind since they don't perform I/O.
3. ShadowRealms can only be created using imperative code, meaning the parent window can in fact "distort" or "limit" the reach of the global constructor via RIC.

My guess is that such script should not be executed inside a ShadowRealm.

[weizman]

My guess is that such script should not be executed inside a ShadowRealm.

Exactly what I was thinking

Thoughts on this?