I, at least, have been assuming that XR features should reuse existing policy-controlled feature names. For example, "camera" for frame-aligned camera frame access in AR and maybe "ambient-light-sensor" for lighting estimation. We should confirm whether this is the case and maybe document some guidelines because it might affect the Feature Policy solution for WebXR and will definitely affect future XR features.
On the one hand:
The existing feature names read more like capabilities than specification names or APIs (i.e., methods).
It seems undesirable to duplicate features.
Reusing feature names makes it easier for polyfills to also work.
On the other hand:
The specification is called Feature Policy, not capability policy.
The specification says, "A policy-controlled feature is an API or behaviour which can be enabled or disabled in a document by referring to it in a feature policy" (emphasis added).
Each feature name is defined by a specification, and the Policy Controlled Features doc is just a non-normative collection of those.
Note that the default allowlist for each such feature is defined in the individual specifications as well.
What would it mean for another specification to come along and redefine the meaning of a string from another specification (even if it is in a consistent way)?
I, at least, have been assuming that XR features should reuse existing policy-controlled feature names. For example,
"camera"
for frame-aligned camera frame access in AR and maybe"ambient-light-sensor"
for lighting estimation. We should confirm whether this is the case and maybe document some guidelines because it might affect the Feature Policy solution for WebXR and will definitely affect future XR features.On the one hand:
On the other hand:
"camera"
, which is already defined at https://w3c.github.io/mediacapture-main/#feature-policy-integration./cc @clelland