RE: [Page Visibility] Spec Updates

Thanks for reviewing Alex!

> In the original thread on the subject I proposed exposing these properties on Document (rather than Window or Navigator).  That has the nice property of extremely decreased odds of collision with global variables in existing scripts.

We all agreed in last week's call that adding properties to the Window object has the concern of collision with global variables, especially with a potentially common used name as "visible". I'm in the process of checking how common the following properties are on the web:

window.visible
window.visibilityState
window.pageVisible
window.pageVisibilityState
document.visible
document.visiblilityState
document.pageVisible
document.pageVisibilityState

We can decide on where to expose these properties based on this research. I actually do prefer exposing these properties on Document.

> In later discussion in the public-webapps thread, we decided to change the meaning of "visible" to " the page content may be at least partially visible", because the spec does not require that user agents report hidden when a non-minimized window happens to be fully obscured by another window.

I agree that visible shouldn't return false (or visibilityState return PAGE_HIDDEN) for the case that a non-minimized window is fully obscured by another window, as this may not be technically easy to determine. We can either explicitly specify that the fully obscured case is not to be considered hidden, or we can go with a more generic definition of visible as "may be at least partially visible". I would prefer the former as it's clear and well defined. We can discuss this on the call tomorrow.

> The draft proposes that visibilityState returns numerical constants, but in the original proposal visibilityState returned strings.

We can have visibilityState return strings, however, the spec should specify pre-defined DOMString constants so that web developers can inspect for capability, rather than read documentation to determine capability. DOMStrings constants have not yet been used in the HTML5 spec, however, per the webIDL spec, http://dev.w3.org/2006/webapi/WebIDL/#idl-constants, DOMStrings constants are legitimate. For example, our constants can change as so:

  const unsigned short PAGE_HIDDEN = "hidden";
  const unsigned short PAGE_VISIBLE = "visible";
  const unsigned short PAGE_PREVIEW = "preview";
  const unsigned short PAGE_PRERENDER = "prerender";

A web developer can check the current state by doing either:

if (window.visibilityState == "hidden")
OR
if (window.visibilityState == window.PAGE_HIDDEN)

A user agent can still expose "webkit-partially-hidden" in advance of "partially-hidden"/window.PAGE_PARTIALLY_HIDDEN being standardized as so:

if (window.visibilityState == "webkit-page-partially-hidden")


> In the original thread the discussion settled on "the page may be at least partially visible, but not in an interactive form" for the semantics of "preview", where the relevant part is that it's non-interactive.  I like the "non-interactive" component being part of the semantics, because I think it captures nicely what a preview means.

Defining previews as "non-interactive" may not capture all preview cases. For example, if you pin Jango.com with IE9 to your Windows 7 taskbar, you can interact with the preview - you can either pause or play the music. Other user agents or Operating Systems may want to take support an interactive preview. Likewise, I don't recommend defining previews as "static" versus "dynamic", as an Operating System or user agent may choose to do either.  I recommend we either define all cases or we keep the preview definition as generic as possible. I prefer the latter.

> In the original draft, conforming user agents MUST return "hidden" and "visible" for visibilityState, and MAY return the other values ("prerender", "preview", "cache", future values) if they choose to.  The reason was that:

This is an excellent point. Except for "hidden" and "visible" states, which must be defined, the other states should be optional as they may not always make sense for a user agent. E.g., a mobile user agent may or may not have the concept of preview. I will update the spec to make the "prerender" and "preview" states optional.

Jatinder