Re: [heycam/webidl] [SecureContext] restrictions on interface vs. interface member are confusing (#153)

So the question is whether we should normatively disallow tautological constructs, do so informatively, or not at all.

If you consider the hierarchy for interfaces or namespaces:

1. interface/namespace
2. (partial interface/namespace)
3. interface/namespace member

and that for interface mixins:

1. interface
2. mixin
3. (partial mixin)
4. mixin member

Annotating any constructs has a cascading effects on those following (within the same list).

So all of the following are redundant. But not all of them are formally disallowed. 

```webidl 
// Your above example;
// tautological but not disallowed.
[SecureContext]
interface Foo {};
partial interface Foo {
  [SecureContext] void func();
};
```

```webidl
// Disallowed.
[SecureContext]
interface Foo {
  [SecureContext] void func();
};
```

```webidl
// Disallowed.
[SecureContext]
partial interface Foo {
  [SecureContext] void func();
};
```

```webidl
// Disallowed.
[SecureContext]
interface mixin Foo {
  [SecureContext] void func();
};
```

```webidl
// Disallowed.
[SecureContext]
interface mixin Foo {
  [SecureContext] void func();
};
```

```webidl
// tautological but not disallowed. (Same as your example.)
[SecureContext]
interface mixin Foo { }
partial interface mixin Foo { }
  [SecureContext] void func();
};
```

Then there's the special case of mixins (which can be included in both annotated and non-annotated interfaces and must be annotated in both.

```webidl
// Allowed
[SecureContext]
interface Foo { }
Foo includes Mixin;

interface Bar { }
Bar includes Mixin;

[SecureContext] 
interface mixin Mixin {
  void func();
};
```

Either way, we must be consistent and fix this open issue.

-- 
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/issues/153#issuecomment-337350301