RE: [Page Visibility] Spec Updates

Regarding the conversation around whether the visibilityState should be PAGE_HIDDEN vs PAGE_VISIBLE in the case that the window is not minimized but is fully obscured by another window:  We all seem to agree that this detection is hard and has odd meaning implications for mobile or tablet devices, but furthermore, I brought up the following point on today's call.  Many, if not most, accessibility tools completely overlap the target window.  For example, magnifier applications demonstrate this.  And depending on the screen resolution, on-screen keyboards also have the possible effect of covering the entire window.  There could be other scenarios as well.  Given this, we should report visible for any non-minimized window, obscured or not.

-Karen Anderson

From: public-web-perf-request@w3.org [mailto:public-web-perf-request@w3.org] On Behalf Of Alex Komoroske
Sent: Tuesday, May 10, 2011 6:02 PM
To: Jatinder Mann
Cc: public-web-perf@w3.org
Subject: Re: [Page Visibility] Spec Updates



On Tue, May 10, 2011 at 5:32 PM, Jatinder Mann <jmann@microsoft.com<mailto:jmann@microsoft.com>> wrote:

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


I won't be able to attend tomorrow's call (I'll be presenting at Google I/O at precisely that time), but for the record I do support document, mainly because of the global variables problem.

> 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 very first proposal for this API explicitly mentioned tabs, and people on the original thread (rightly) pointed out that the API should be as desktop-UI agnostic as possible.  The more generic wording comes directly out of that, although it might have gone a bit too far to the generic.  Leaving it more general has the (slight) benefit that in the future if some UA decides to implement fully-obscured-counts-as-hidden they can.  However, I don't feel strongly about this point.


> 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")



This seems like a good way to go to me.

> 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.

I think you convinced me that the latter is better. :-)

> 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.