Page Visibility LC issues

(as of Jul 17)

hidden attribute
The hidden attribute on Document is potentially confusing with the hidden attribute existing on all HTML elements, especially as the Document object sometimes shares such global HTML attributes (dir and numerous event handler attributes). Maybe isVisible would be better?
visibilityState as DOMString.
visibilityState should presumably return a DOMString
Using strings in APIs
We use strings in a number of APIs and it is clearly a better approach however none of these APIs currently expose them as constants and I do not think there is a good reason to do that. Examples of such APIs are XMLHttpRequest (the responseType attribute) and the HTML Canvas 2D Context (numerous attributes).
DOM reference
I think it would be better if the DOM dependency was on DOM4 as that is what we want implementors to implement.
partial interface?
Instead of using [NoInterfaceObject], a different interface name, and implements, please simply use "partial interface Document".
Thought I had just before sending, should this document say something about privacy implications?
WebIDL reference missing
you need to reference Web IDL and state you are using it.
Introduction and misc edits
In some games the user might want to let the game clock tick even while it isn't active. Having a game always kick me out just because I'm not watching (but I can e.g. hear the game sound and switch back before something bad happens) isn't nice.

s/email/messages/g (or 'email', it's a mass noun)

s/Javascript/JavaScript/g [...]

screen definition
I don't think "screen" is defined in your specification. So what do I do if I'm using a Voice based browser?
Please require all of [VENDORPREFIX, NAME] to be ASCII.
Document.PAGE_REVIEW optional
Is it correct that document.PAGE_HIDDEN and document.PAGE_VISIBLE must be supported, but document.PAGE_PREVIEW is optional? Why isn't it also required?
Using MUST
General comment - use MUST where appropriate, in upper case section 4.2 hidden attribute change "returns" to "MUST return" in two places.
DOMStrings are never signed
The current draft says, in the idl:
   readonly attribute unsigned DOMString visibilityState;
The 'unsigned' should go away, presumably.
What should the visibility API return on documents without an associated Window?
One option is to attempt to grovel around for a Window and then return the state of its top level browsing context.

Another is to just always return the same thing for documents without a Window.

display:none iframes
At the moment, the spec says to return the visibility state of the toplevel browsing context containing the iframe, as far as I can tell. Why is that desirable?

In particular, given an iframe script can always get the visibility state of the toplevel browsing context simply by doing top.document.visibilityState. So having document.visibilityState simply mirror that saves about 4 characters of typing. On the other hand, there may well be good use cases for detecting the visibility state of display:none iframes, right?

Are visibility change events synchronous?

If there is a visibility change, is the visibility change event fired synchronously?

Note that this is sort of page-observable: a page could poll the visibilityState and see whether it matches the previous state without having seen an event. Then again, it's hard to tell that situation apart from one where some other script called stopImmediatePropagation on the event and then dispatched a new event...

My personal preference would be to allow or require asynchronous firing; the alternative involves, e.g. a tab switch triggering synchronous JS execution before it completes, which is not great for users navigating across tabs using the keyboard.

Need to define what sort of event visibilitychange is
Specifically, what interface it implements.

Can we just reference the "fire a simple event" definition from html5?

Also, is this event cancelable? I'd think not, but I'm not quite sure what it really means to be cancelable or not for events without default actions.

Target of the visibilitychange event is not defined
It's obvious that it should be targeted at the document whose visibility changed, right?
Need to define interaction with page navigation
In particular, does visibility state change when documents are unloaded?

What if they're going into the history cache or coming out of it? Does the visibility change notification fire in that case, and if so, how is it ordered with pageshow and pagehide?

I would like to strongly suggest that browsers implementing the Page Visibility guidelines identify themselves by using a X-Page-Visibility (or similar) header. This would give webmasters the ability to utilize the suggestions put forth in the Page Visibility guidelines with increased efficiency. It also would give them the ability to block such requests as desired.

Suggested attribute and possible values:

X_PAGE_VISIBILITY: (hidden|visible|preview|prerender)

Misc edits
Interface to be notified of user idleness
I would like to propose an interface enabling site developers to detect when there is a state of overall user idleness on a system (defined as no activity on a system's keyboard/mouse/other direct human interface devices) for a period of time defined by the web developer. I am posting it here because I think the Page Visibility specification's goals are most closely aligned with this proposal
Missing definitions

Is the reference to top level browsing context here really what's wanted? For example if one document opens a page using then the user could hide the top level browsing context while still having the child browsing context visible.

[preview, etc.]

when visibilityChange gets fired?
Do we need to clarify in the spec that the event fires between load and pageshow (i.e., add a similar hook to and that it only fires if the visibility state has changed from the document's initial visibility state?