(as of Jul 17)
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 should presumably return a DOMString
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).
I think it would be better if the DOM dependency was on DOM4 as that is what we want implementors to implement.
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?
you need to reference Web IDL and state you are using it.
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 [...]
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.
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?
General comment - use MUST where appropriate, in upper case section 4.2 hidden attribute change "returns" to "MUST return" in two places.
The current draft says, in the idl:readonly attribute unsigned DOMString visibilityState;The 'unsigned' should go away, presumably.
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.
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?
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.
[...] the User Agent MUST queue a task that when run, synchronously sets the new values for the visibilityState and hidden IDL attributes, and then fires a simple event [...](accepted)
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.
It's obvious that it should be targeted at the document whose visibility changed, right?
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)
[...]
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
Is the reference to top level browsing context here really what's wanted? For example if one document opens a page using window.open then the user could hide the top level browsing context while still having the child browsing context visible.
[preview, etc.]
Do we need to clarify in the spec that the event fires between load and pageshow (i.e., add a similar hook to http://dev.w3.org/html5/spec/single-page.html#the-end) and that it only fires if the visibility state has changed from the document's initial visibility state?