- From: Rick Byers <notifications@github.com>
- Date: Wed, 23 Nov 2022 09:45:17 -0800
- To: whatwg/webidl <webidl@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <whatwg/webidl/issues/1236@github.com>
Reading over the definition of Exposed, LegacyNoInterfaceObject and the history in #365 and #350 I'm left quite confused on what WebIDL's position is on interfaces without an ES interface object. Does WebIDL take the position that all new interfaces should be exposed on at least one global interface? Why? If not, then what's the "non-legacy" way to mark an interface as not being exposed? To what extent should this be discussed somewhere in the WebIDL spec vs. maybe the TAG design principals? Given that the platform and applications share a global namespace, it seems that there's a tension here. As we add new APIs to the platform we often can't expose new generic property names on `window` because doing so often leads to breaking some websites, such as those which conditionally set global properties they depend on only when its previously undefined. So do we need to use non-generic names for all new interfaces? Or can we avoid worrying about this for interfaces without constructors by just not exposing them? This is coming up now because in blink we're [trying](https://groups.google.com/a/chromium.org/g/blink-dev/c/j7vOAkMbu_M/m/OmlnogDoAgAJ?utm_medium=email&utm_source=footer) to expose the [Report interface](https://w3c.github.io/reporting/#idl-index) and needing to do a bunch of web compat analysis to figure out whether or not we can do so safely. What is the cost/benefit tradeoff of exposing interfaces like this one? -- Reply to this email directly or view it on GitHub: https://github.com/whatwg/webidl/issues/1236 You are receiving this because you are subscribed to this thread. Message ID: <whatwg/webidl/issues/1236@github.com>
Received on Wednesday, 23 November 2022 17:45:29 UTC