Re: [heycam/webidl] Define the `[CrossOriginIsolated]` extended attribute. (#883)

> > > Another point is that do we allow a interface with SecureContext to contain a member with CrossOriginIsolated or a interface with CrossOriginIsolated inherits from another interface with SecureContext? It seems they are valid use cases to me.
>
> > Yes. We would want to support this.
>
> So we want them to be not mutually exclusive?

I want the following to be legal so that we can restrict new things added to old interfaces (I'm thinking of the `Performance` interface in particular, which isn't currently locked to secure contexts, but wouldn't it be nice if it was?).

```
[SecureContext]
interface VerySecureThing {
  Promise<float> secureNumber();
  [CrossOriginIsolated] Promise<boolean> verySecureBoolean(); 
}
```

@annevk does not want the following to be legal:

```
[SecureContext,CrossOriginIsolated]
interface extraSuperSecureThing {
  ...
};

[CrossOriginIsolated]
interface SecureThing {
  ...
  [SecureContext] bool verySecureBoolean();
};

interface RegularThing {
  ...
  [SecureContext,CrossOriginIsolated] bool verySecureBoolean();
};
```

So, `SecureContext` should not be specified when `CrossOriginIsolated` applies to a construct. The inverse is possible, as `CrossOriginIsolated` is more restrictive than `SecureContext`.

(Sorry this is confusing.)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/heycam/webidl/pull/883#issuecomment-629142406