The discussion around adding backgroundBlur to the spec uncovered a pattern that I think we may see more often.
A feature can be set from the browser
The same feature can be set by OS-level UI
In some environments, browser can override the OS-level setting; in other environments, it cannot.
With backgroundBlur, we handled this by saying:
The OS-level setting is the default for the value
If the OS-level setting can be overridden, capabilities for that constraint return {false, true}
If the OS-level setting can't be overridden, capabilities return just a single value (the current one)
That way, an app can detect whether the function is on or off, and whether it can change it or not.
It might be worth pulling out this pattern as a documented pattern, so that other features that behave like this can refer to it instead of re-explaining it for every constraint.
(I note that the description in the spec for backgroundBlur doesn't go into details on this pattern either. Might be worth improving.)
The discussion around adding backgroundBlur to the spec uncovered a pattern that I think we may see more often.
With backgroundBlur, we handled this by saying:
That way, an app can detect whether the function is on or off, and whether it can change it or not.
It might be worth pulling out this pattern as a documented pattern, so that other features that behave like this can refer to it instead of re-explaining it for every constraint. (I note that the description in the spec for backgroundBlur doesn't go into details on this pattern either. Might be worth improving.)
Thoughts?