I’ve just found this page on MDN: https://developer.mozilla.org/en-US/docs/Web/Security/Secure_Contexts/features_restricted_to_secure_contexts
It’s essentially two compat tables, however it currently uses two traditional tables. I understand that this is most likely an issue of being able to generate tables with the required information based on the compat data?
Well, some features are only available in secure contexts from the start, which makes them not have the secure_context_required sub‑feature, as it’s used only when the implementation version differs from the restricting behind secure context version (the second table).
Shouldn’t that case be detectable based on the version of the browser it was added in, since the secure context policies were introduced at a specific point in the browser release history? Or is the issue that there’d be exceptions?
The issue is that there’d be exceptions1 and we can’t just use BCD directly for this because of that.
1 Newer secure context only APIs are restricted to secure contexts by default from the get‑go, which means that BCD doesn’t include secure_context_required as it’s only used when an API is restricted to secure contexts after it has already been shipped.
Right, that’s what I was talking about. There’s a point when browsers decided that new (web) APIs would only be available in secure contexts. Thus there should be a version number, from which all newly added APIs would only be available in secure contexts, thus the list of APIs being everything that was added >= that version.
I fear that there would still be exceptions to that rule, as in APIs that weren’t added for secure contexts only after that point.