Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New principle: Document whether to add things to Document, Navigator, Window, or SomeOtherInterface #448

Open
jyasskin opened this issue Jun 29, 2023 · 2 comments

Comments

@jyasskin
Copy link
Contributor

API designers often wonder how to namespace their new thing, and I don't think we have any existing guidance. #426 has some argument for and against using Window, but I think the principle should be broader than that. Some considerations:

Navigator "represent[s] the identity and state of the user agent", so it should hold objects that tend to be the same across different documents.

Document and Window are nearly equivalent, but adding things to Window means developers can use them without an object prefix, and they also risk colliding with things developers defined. Maybe we should say that infrequent use argues to put things on Document?

SomeOtherInterface.Thing and SomeOtherInterfaceThing are also nearly equivalent, as discussed in #426.

I'm sure other folks can think of more considerations. The more we can give these decisions a technical basis, the less likely they are to turn into prolonged bikeshedding discussions.

@bathos
Copy link

bathos commented Jun 29, 2023

It may be worth noting that, ahead of considerations of semantic appropriateness, the lifecycles & relationships of candidate interfaces can impact whether they’re viable options. For example, the Window’s associated CustomElementRegistry couldn’t have belonged to the Document instead — though the conditions where this both occurs and is observed are uncommon, a Window’s associated Document can change one time (the registry could not have similarly changed underfoot soundly).

(I suppose a Document member could have steps like “return the associated Window’s associated Foo” to get around that, but personally I wouldn’t expect non-DOM/non-DOM-related specs to want to extend Document much anyway?)

@LeaVerou
Copy link
Member

LeaVerou commented Jul 1, 2023

Completely agree about documenting guidance about this. Another consideration is whether the API in question may ever be useful in non-browser runtimes, we don't want to e.g. hang something on Navigator that may eventually become useful in Node and have to define a new API for it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants