Remove secure context warnings from XR member pages

[Elchi3]

Not sure if we have guidelines about this but to me it makes no sense to have this (loud) banner on every member page. On an interface level it makes sense to warn about availability of the whole API. However, at a stage when you are concerned with the API members already, I don't think secure context is a thing you need to worry about.

[dontcallmedom]

in case this is turned into a guideline of some sort, just wanted to note that [SecureContext] can be and is being used (e.g. navigator.registerProtocolHandler) at the interface member level as well (in which case, having the annotation surfaced on the member page is absolutely appropriate and useful

[hamishwillee]

@Elchi3 Do you plan to create a guideline or discussion for this?
Perhaps in https://developer.mozilla.org/en-US/docs/MDN/Structures/Macros/Commonly-used_macros#page_or_section_header_indicators ?

FWIW I agree that the huge icon/banner on the "entry point" to an API makes sense (e.g. navigator.registerProtocolHandler) but not on individual members that you probably only get to after you already know about secure contexts. On the other hand I'd be completely happy if the banner was a very much more subtle icon on any page, in particular if it was auto-generated from BCD data.

[wbamberg]

On the other hand I'd be completely happy if the banner was a very much more subtle icon on any page,

Yes, I agree. I think this is is part an issue about the bad UX of the "secure context" banner. We have talked before about having some space at the top of the page where we could include indicators for various things, including this (but also things like "available in workers" or "required permissions"), and avoiding the "stack of banners" scenario we get on MDN sometimes.

in particular if it was auto-generated from BCD data.

I've said this before but I'm uncomfortable with just sticking things in BCD because it's there. Traditionally BCD has been for, well, browser compatibility data - things that describe a specific browser's support for a feature. Secure context is specced behavior, so it doesn't belong in that category.

But maybe this ship has sailed and BCD is now just "data about the web platform".

This also causes practical issues though, because it works best if all the MDN pages that might want to express this had a BCD counterpart. But for example API overview pages don't live in BCD, but we might want to say "this whole API requires a secure context". (We don't at the moment: https://developer.mozilla.org/en-US/docs/Web/API/WebXR_Device_API, but maybe we should?)

Also, this is only applicable to Web APIs. If we include it in BCD this isn't reflecting that constraint - we could add it to a CSS property, although it makes no sense there.

If it were me I'd:

• use a front matter item for this, and other things (like available in workers, or required permissions)
• have page types for WebAPI overview pages, interfaces, methods, properties, and events
• allow those page types to include this front matter item

[hamishwillee]

in particular if it was auto-generated from BCD data.

I've said this before but I'm uncomfortable with just sticking things in BCD because it's there. Traditionally BCD has been for, well, browser compatibility data - things that describe a specific browser's support for a feature. Secure context is specced behavior, so it doesn't belong in that category.

I think it should be in BCD data because the implementation is version and browser dependent - i.e. for a user it is a compatibility issue. So not just sticking in because it is there. But perhaps I misunderstand.

In any case, sounds like we'd both like little icons :-)

[wbamberg]

in particular if it was auto-generated from BCD data.

I've said this before but I'm uncomfortable with just sticking things in BCD because it's there. Traditionally BCD has been for, well, browser compatibility data - things that describe a specific browser's support for a feature. Secure context is specced behavior, so it doesn't belong in that category.

I think it should be in BCD data because the implementation is version and browser dependent

It isn't though, it's specced behavior: https://immersive-web.github.io/webxr/#xrsession-interface. A browser can't just choose to expose such an interface in unsecure contexts, not if it wants to remain compliant. If a browser did make this choice to diverge from the spec, absolutely that should be in BCD. But the fact that it's secure context only is just like the fact that it returns a Promise, or throws XYZ exception in a particular case.

I mean of course "the implementation is version and browser dependent", in the sense that everything is. But that leads to putting everything in BCD.

[dontcallmedom]

I'm with @wbamberg on that one - I don't think BCD needs to be the funnel for all and any structured data into MDN content.

FWIW, webref provides a convenient way to retrieve the vast majority of IDL fragments from which the API pages derive, and so it should be relatively easy to extract information to be automatically imported by Yari to set flags (e.g. secure-context only, available in workers, …), without going through BCD.

This is similar (although distinct) to openwebdocs/project#44 (which also alludes as an aside to using webref to replace information about inheritance)

[hamishwillee]

OK, thanks for the explanation!