Re: [sensors] Define behavior when visibilityState != "visible"

@marcoscaceres thanks for rewriting the Page Visibility spec spec with
 those hooks! I wasn't aware this was happening -- I'd have felt much 
better with the Vibration API (no pun intended) if the visibility spec
 would have had those hooks when we spec'd vibrate().

@tobie I think even more direct drop in replacement for the step 3 in 
[processing vibration patterns][0] would be:
>If the result of running the [steps to determine if the document is 
hidden][1] is true, then return false and terminate these steps.

I'll update the Vibration API ED if that looks okay.

Then, if we go back to sensors, would something like the following be 
appropriate:

>Each `Sensor` object has a task source called the sensor task source,
 initially empty. A sensor task source can be enabled or disabled, and
 is initially enabled. When enabled, the event loop must use it as one
 of its task sources. The task source for the tasks mentioned in this 
specification is the sensor task source.

>When the [visibility state][2] of the Document in the top-level 
browsing context changes, let _current visibility state_ be the result
 of running the [steps to determine the document visibility state][3].
 If _current visibility state_ is "visible", enable the sensor task 
source, otherwise, disable it.

Do we need a new hook to tap into for visibility state changes, or is 
this okay?

[0]: 
https://www.w3.org/TR/vibration/#dfn-processing-vibration-patterns
[1]: 
https://w3c.github.io/page-visibility/#dfn-steps-to-determine-if-the-document-is-hidden
[2]: https://w3c.github.io/page-visibility/#dfn-visibility-states
[3]: 
https://w3c.github.io/page-visibility/#dfn-steps-to-determine-the-visibility-state

-- 
GitHub Notification of comment by anssiko
Please view or discuss this issue at 
https://github.com/w3c/sensors/issues/81#issuecomment-179218730 using 
your GitHub account

Received on Wednesday, 3 February 2016 13:05:04 UTC