Earlier quoted context omitted.
> The blanket "yes/no" setting isn't nearly enough for these kinds of things. why not? These are all things the current underlying implementation checks for, and report via the visibility api, which is just a boolean effectively. The user should be able to set a toggle, where the visibility api will return "true" (aka visible), for all of these underlying checks that the browser does. E.g., the visibilityChange event…
> why not? Because some of them are harmless, some of them are less harmless. Same goes for all the other APIs that require user permissions. In the end the user will just click "yes" on all of them. > The user should be able to set a toggle, where the visibility api will return "true" (aka visible), for all of these underlying checks that the browser does. Does the user know what those checks are? Did you know which…
if the user wants the computation to continue, despite being not visible, the site should not be able to override it. It would be anti-user otherwise.
often, i would see video sites _not_ prebuffering when the page is not visible. Or, deliberately switch over to a low resolution version of the video when the visibility changes - twitch does that. Even if i have the video overlay playing outside the browser window (so technically, it is visible, just not according to the API).
Essentially, if the user has the know how to switch this preference (and it would be per site, or even per session, like mic or camera), they would know the consequences.
> require user permissions.
It's not a permission per se, but a toggle, so the user might turn it on or off depending on their circumstances. They don't need to understand it - they can just leave it on default as what the browser currently does if they don't understand, or don't have any problems with the site's behaviour.