Re: [webidl] Add a [SecureContext] operator attribute (#65)

Assuming we're going with the "throw/reject" approach and not the "exposure" approach, this patch looks sensible to me.

In an ideal world, I would really prefer we control this through exposure rather than errors, for reasons I've stated before.  Is it possible to have use exposure as a general approach and still be consistent with w3c/webappsec-secure-contexts#10?  The case you have to deal with is:

1. `if (navigator.secureOnlyFeature) {...}`
2. `document.domain = document.domain`
3. `navigator.secureOnlyFeature.doSomething()`

What if we were to break the symmetry of w3c/webappsec-secure-contexts#10, in the following way: If you touch something secure first, then `document.domain` throws.  If you touch `document.domain` first, then you can't see anything that's `[SecureOnly]`.  That's a little bit magical, in that the `[SecureOnly]` stuff gets yanked from the DOM when you touch `document.domain`.  But it's not clear to me that hiding all of those things is any more work than telling them all to throw.


---
Reply to this email directly or view it on GitHub:
https://github.com/heycam/webidl/pull/65#issuecomment-156246766