[SecureContext] restrictions on interface vs. interface member are confusing

[domenic]

Previously at #121 (comment)

The spec currently says

The [SecureContext] extended attribute MUST NOT be specified on both an interface member and the interface or partial interface definition the interface member is declared on.

It's not clear what "declared on" means especially in the context of partial interfaces. E.g. consider the situation

[SecureContext] interface Foo {};
partial interface Foo {
  [SecureContext] void func();
};

[domenic]

@tobie this may be fixed with your recent overhaul; can you check?

[tobie]

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.

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

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

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

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

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

// 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.

// 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.

[tobie]

Discussed this offline. Agreed to keep the rules normative but simplify them wherever possible and make them consistent.

Additionally, these are rules that seem worth marking up in a way that Bikeshed and ReSpec can Warn their users about.

[Ms2ger]

Improved somewhat in #763.