-
Notifications
You must be signed in to change notification settings - Fork 2k
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
Representing WorkerLocation and WorkerNavigator similarly to other worker-exposed interfaces #9125
Comments
So, what are our options here? I guess the mixin guideline clashes with the worker guideline here. It seems like we should proceed strictly per the new mixin guideline, so that we capture the correct data for both WorkerNavigator and Navigator. However, it does't make much sense to document these APIs twice (we don't do this when have It is sad that specs aren't doing that here, but can we act as if this was done using that mechanism? What would that mean for BCD / MDN ? I find the mixin guideline quite clear but maybe it is the worker guideline that is a bit underspecified? Is worker support clearly captured in BCD? I guess there is an issue somewhere and that needs solving first. Pointers appreciated. |
It's not been done because there is some compat risk, but I've filed whatwg/html#6390. For MDN/BCD, I think it'd be quite fine to document things as if there was a single interface, and note only somewhere on MDN that actually there's a I don't think the worker guideline really works for communicating what things aren't supposed to be exposed in workers, since that would result in a lot of entries with all false values. |
This also clashes with omitting irrelevant features. Maybe BCD needs a shorthand for non-features ("this isn't supported and it isn't supposed to be supported")? |
https://xhr.spec.whatwg.org/#xmlhttprequest is another situation like this, where I would say that for the most part, what's needed is for MDN do make it clear whether an API works in workers or not. In terms of browser support, it's really only useful to note a lack of support, entries that amount to "was always there in workers as it should have been" or "was never in workers and shouldn't be" are pretty unhelpful. |
This is blocking #8929 now, since demixing the remaining Navigator* mixins would result in duplicated entries. It's possible the right answer here is to actually accept two BCD entries for these, and to link both BCD tables on the single MDN pages. |
OK, thinking on this a little bit today. Would this be a pretty comprehensive solution?
If that doesn't work, what's missing or what am I breaking? |
That sounds almost perfect, but I have two points of doubt.
How can readers tell that
Do you have an example or this? The only case I know of is https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/responseXML but that's sort of accidental and not information I think anyone can use. |
My inclination is to treat this as a content problem for
No, not really. I was just trying to cover all the cases. I suppose we could just as easily say, "Never add a worker support entry, whether or not it has worker support, if it's specified as not having worker support." Though maybe that would be bad news if a feature is ever removed from workers only. |
I discovered this thread today. I agree with it, with one difference: there are very few cases were there are different interfaces for the window case and the worker case:
In the spec, there are a few mixins related to I think we should finish the demix here, as I see value of having "It is an interface, we have an entry, both in content and in bcd". I agree there is a bit of redundancy here, but:
For the |
Just to be sure we're all working from the same understanding, here are the various interfaces and mixins at play:
I agree that the problem described in this issue is fairly small, but it's not "mostly on old useless features". New properties are added to The duplication on MDN seems especially unhelpful: It is technically correct that these are separate interfaces, but it seems to me that at least on MDN it would be better to merge them. If not also merged in BCD, maybe that single page could include two compat tables. My concrete suggestion is deleting I don't think this needs to block demixing however, demixing |
I've read in both specs that define these two features (userAgentData and permissions) and I don't understand why they are available to both Navigator and WorkerNavigator. So, I'd have trouble as well to document them separately in a way that makes sense to MDN readers. Is worker exposure just there because "it couldn't hurt" or is there some other reason? What practical advise could be documented on worker specific documentation pages to make the currently unhelpful pages more helpful? If there is no reason, then I agree that separate pages are unhelpful as there isn't really anything to document separately other than "it works in both contexts", so |
In whatwg/html#6390 I speculated that it's just because these APIs were made available to workers before Web IDL had the In that same issue it was pointed out that For |
I've sent mdn/content#6818 to fix a bunch of things I found when looking at MDN pages around this issue. |
Aha, okay. I guess that hints that we should rather have separate pages for
Seems like here we could then apply your suggestion to use |
Yes, or to take the other side, it's important to have examples for I don't have enough experience with how web developers understand and misunderstand documentation to have an opinion about what we should do here.
Yes, if we don't merge |
I think a content issue would be great to get that figured out properly.
Sounds good to me. I guess we have a resolution then? Is there work left in BCD? Looks like all 4 interfaces exist in the data already. |
I've filed mdn/content#6856, closing this. |
Is this fixed though? We don't have a guideline for how we're supposed to record this data in BCD and I'm not sure where that work would be tracked elsewhere. |
The conclusion is to just not do anything special for |
OK, great. Thank you! |
The typical way that interface exposure is controlled is via Web IDL extended attributes like
[Exposed=(Window,Worker)]
on a single interface. However,WorkerLocation
andWorkerNavigator
and predate this mechanism, and are instead separate interface with a subset of the members.Navigator
is only exposed in the window context andWorkerNavigator
is only exposed in workers.All members come via mixins, and because of this these members are only documented once on MDN, see for example https://developer.mozilla.org/en-US/docs/Web/API/NavigatorID/userAgent. Web developers would just use
navigator.language
orlocation.href
in both window and worker scripts, so this seems appropriate.In #8929 we're getting rid of mixins, and no doubt we'll find that that
navigator.userAgent
was supported earlier onNavigator
than onWorkerNavigator
. That's good, but the way window vs. worker support will be represented in BCD for these interfaces will be different than anything else. Maybe that's OK, but I want to raise the issue explicitly.First raised in #9079 (comment).
The text was updated successfully, but these errors were encountered: