If it's an interface, a namespace, and it doesn't"Exposed" as extended attribute, then warn.
This is basically to make things more explicit and avoid issues where interfaces aren't accidentally exposed by vendors.
Pull request is here: https://github.com/heycam/webidl/pull/423.
I might just get ReSpec to add this (if not present), instead of annoying Editors about it. Editors can then override it if they need to.
Doesn't that defeat the purpose of making it mandatory, though, which is precisely to get editors to think about it?
Ah, I was viewing it from implementer's perspective of copy/pasting to generate the binding in c++.
To think about it, I would expect [Exposed] to provide some guidance (or it it somewhere else?): https://heycam.github.io/webidl/#Exposed
Right now, it's quite algorithmic and not that fun to read. What should I point to? Just the bug?
I see "Example 52" might actually serve the purpose... maybe we should move that up in the IDL spec?
WIP: If it's and interface, a namespace, or a mixin, and it doesn't have "PrimaryGlobal", "Global", or "Exposed" as extended attribute, then warn.

Exposed isn't required on mixins.
Makes sense. Misread the spec.
(Sorry for the terse comment, I was on my phone).
I need to revamp heycam/webidl#423 given mixins changed a whole bunch of things it was touching. I'll do so shortly and will do my best to include your feedback in that PR.
(Sorry for the terse comment, I was on my phone).
np :)
I need to revamp heycam/webidl#423 given mixins changed a whole bunch of things it was touching. I'll do so shortly and will do my best to include your feedback in that PR.
Ok, I'm also adding a dedicated idl-validator to ReSpec now. Will make it easy to add new warnings... if it proves useful, we could push it to WebIDL2.js, as it just consumes WebIDL2.js output... would be cute to parse and then validate.
How about supporting this on WebIDL2.js side?
@saschanaz, could do... but we need to work out if WebIDL2.js is a non-validating parser (mostly how it works today), or if we need to beef up validation. Otherwise, we could build a separate validator that takes input from WebIDL2.js (I made a small start on this elsewhere).
Or we may add .validate() method to the webidl2.js.
.validate() would be really useful... I'm mostly thinking about web platform tests making primary use of it.
Thinking out loud here, but the trade off with .validate() instead of, say, parse(idlText, {validate: true}) is that we lose line numbers and character position of errors.
Also the method/option name should be more intuitive, validate is somewhat confusing to me as a parser always validates the syntax.
True that... should we move this discussion to the other repo? This could potentially be quite a large project - but I'm totally keen to discuss it further. And definitely something we could involve a GSoC #1502 student on - as it would require a ton of tests.
Yes, please open an issue and link back 馃憤
Also applies to namespaces.
Heh, was just going to ask which one of the two projects should support this 馃榿
I think this can be closed now, thanks to #2416 馃帀
I updated my documents with WebIDL to add [Exposed=Window], now (with 24.30.3) I'm seeing an error "Couldn't match "Window" to anything in the document or in any other document cited in this specification: html.
It was never clear to me that a spec using WebIDL outside of the DOM would need to be exposed to "Window", and how an automatic cite to html gets made here, but clearly something needs to be done, but I'm not clear what. Is this some transitional issue? Is there something more appropriate I should expose?
I'm seeing an error "Couldn't match "Window" to anything in the document or in any other document cited in this specification: html.
@gkellogg Can you please share the document link that has the error? I can help with this one.
That error deserves a guide message! Oops, misread
You should see it at https://w3c.github.io/json-ld-api/, but I don't see it there. I see it running locally (using python3 -m http.server), which is odd.
@gkellogg Weird, can't reproduce it locally here. Could you remove your IndexedDB data and try again, as the local data might be broken?
Most helpful comment
@saschanaz, could do... but we need to work out if WebIDL2.js is a non-validating parser (mostly how it works today), or if we need to beef up validation. Otherwise, we could build a separate validator that takes input from WebIDL2.js (I made a small start on this elsewhere).