New text for guidance on exposing interfaces everywhere #510
Conversation
I've drafted a set of criteria for which interfaces to expose universally on all globals, at w3ctag/design-principles#510. URLPattern looks like it fits those criteria and is useful to have in any environment.
|
this is great, thanks @ptomato for putting the time on this |
| Additionally, anything annotated with {{SecureContext}}, | ||
| or relying on an event loop, | ||
| should not be exposed everywhere. | ||
| Not all global scopes are secure contexts | ||
| or have an event loop. |
There was a problem hiding this comment.
I'm not sure about excluding [SecureContext] things from [Exposed=*]. Won't [SecureContext] itself exclude those items from global scopes where they'd be inappropriate?
| Additionally, anything annotated with {{SecureContext}}, | |
| or relying on an event loop, | |
| should not be exposed everywhere. | |
| Not all global scopes are secure contexts | |
| or have an event loop. | |
| Additionally, anything relying on an event loop | |
| should not be exposed everywhere. | |
| Not all global scopes have an event loop. |
There was a problem hiding this comment.
Thanks for the review!
My motivation for this was to get exactly the same set of exposed APIs in ShadowRealm regardless of which global scope created the ShadowRealm. I could go either way on this; we could remove this sentence from the guidance and specify in whatwg/html#9893 that ShadowRealm scopes are never secure contexts. That would have the same result, I think.
There was a problem hiding this comment.
Since browsers are going to differ in which APIs they implement anyway, I don't think there's that much reason to worry about getting exactly the same set of exposed APIs in ShadowRealm. By contrast, I do think it's important that pure-computation APIs which happen to be restricted to secure contexts, like crypto.randomUUID(), should be available in ShadowRealms when they are themselves running in secure contexts.
The stated intention of browsers in restricting features to secure-context-only is to encourage the use of secure contexts for all new applications, with this being assumed (IMO incorrectly) not to be a very large cost to the usability of the feature because applications should be in secure contexts anyway so developers following best practices (i.e. secure contexts) shouldn't even notice. That will not be true if we have this restriction here.
|
@zcorpan Intuitively I disagree with your argument in whatwg/webidl#1119 (comment), at least given the guidance in this PR. The downside of requiring review for every new kind of realm is that when we add a new realm type, there's going to be a long string of paper-cuts as developers reach for various utility functions and notice that they haven't yet been added to this particular realm. |
Here's an initial draft for text on exposing interfaces everywhere. It's similar to the text I wrote in #509 and the examples I gave there.
Closes: #509
Preview | Diff