Content suggestion: Add one-liner to former WindowOrWorkerGlobalScope methods

[tjcrowder]

What is the new suggestion?

See this Twitter thread: Now that the potentially-confusing WindowOrWorkerGlobalScope prefix is gone, I suggest adding a one-liner paragraph near the top saying that the global is provided both by Window and WorkerGlobalScope (with links). Something like:

Available as a global in both windows and workers (see Window and WorkerGlobalScope).

Why is it important or useful?

The one good thing about the old prefix was that if you were "in the know," it told you right away whether something was Window-only (like document) or both (like encodeURIComponent).

Other supporting information

We'd make this change on the same set of pages that used to have the WindowOrWorkerGlobalScope prefix. I don't think we need this for Window-only or WorkerGlobalScope-only properties; it looks like they already have a prefix.

I should be able to work on this next week if you'd assign it to me. Any hints on how to approach it, etc., very welcome!

[tjcrowder]

Probably best to remove self. in examples (for instance, here) at the same time. I think that's a holdover from when using self. as a prefix on the page title was being considered.

[tjcrowder]

@Josh-Cena @sideshowbarker Do you still want this? If so, I can finally (!) make good on my promise to do it.

But I see that things like setTimeout and Blob already have a note on them:

Given that, is this still useful? If so, what form should it take? If not, I'll close the issue.

Sorry to have flaked on it. :-(

[sideshowbarker]

Howdy @tjcrowder. Thanks for following up. @OnkarRuikar, is this covered now by the work you've been doing?

[OnkarRuikar]

Here is the Tweet thread for the ready reference:

---

At the moment we have {{AvailableInWorkers}} macro to add following notes :

At the moment we do not have a mechanism to tag a page with following:

1. available as global in both Window and Worker scopes
2. available as global in only Window scope
3. available as global in only Worker scope
4. available in both Window and Worker scopes
5. available in only Window scope
6. available in only Worker scope

There are already too many status banners crowding page tops, e.g. Barcode Detection API and PaymentAddress#country. So introducing a new one won't be welcomed easily. May be we could repurpose the same {{AvailableInWorkers}} macro to show appropriate info.

---

Does automation already exist that could do that? Or does it take grunts like me to add it (hopefully add some macro)? ("Like me" because hey, I'm the one saying it "would be good," so put up or shut up.😀)

The automation to add such status macros is being developed. Once it is up and running we can easily add and keep updated the statuses mentioned in this post. The automation may take time to go live depending on the interest shown by the top brass.

One could use webref to determine the exposure set of global APIs, and in fact all APIs.

I agree. We are trying to utilise @webref/idl package for the automation but it doesn't have the complete data. Our script we'll have to do some inferences and some web features we need to curate manually.

There’s no place to put that information in BCD though, maybe there should be?

Yes, BCD couldn't be burdened more. We are planning to create a separate repo for hosting such info.

Given that, is this still useful? If so, what form should it take? If not, I'll close the issue.

This GitHub issue proposes to tag API pages with detailed scope info. So I say we keep it open to track this.
The automation is about just adding the macros/notes to the pages. Actually, first we'll have to start a discussion on MDN to get an approval to add an accurate scope info banner to all the Web API pages.

@OnkarRuikar, is this covered now by the work you've been doing?

Actually the work is about secure context statuses. But I have proposed to involve {{AvailableInWorker}} status macros as well.

[wbamberg]

Ah, this intersects with https://github.com/orgs/mdn/discussions/360 and #32040.

[wbamberg]

I think we should close this issue in favour of the one outlined in https://github.com/orgs/mdn/discussions/360, unless people have objections to that (but since that discussion has been open for almost a year and I've started to implement it, I hope not to see any) 🤞 .

[tjcrowder]

I agree, https://github.com/orgs/mdn/discussions/360 covers this. I see several agreements as votes on @wbamberg's comment above, so I'm going ahead and closing this, but someone can reopen if that's premature.