Re: Page Visibility Simplifications

Hi Jatinder,

Thanks for starting this thread.  I've replied inline.

On Tue, Jun 21, 2011 at 11:21 AM, Jatinder Mann <jmann@microsoft.com> wrote:

>  As per discussion in our last conference call,
> http://lists.w3.org/Archives/Public/public-web-perf/2011Jun/0074.html, the
> issue was raised that we should consider simplifying the Page Visibility
> spec by removing the document.visibilityState and relying only on the
> boolean, document.hidden, that describes whether the page is visible to the
> eyes or not. This would essentially remove the optional sub-states of
> PAGE_PREVIEW and PAGE_PRERENDER.
>

Although I'm in favor of simplifying the API, I think there are use cases
that require such information to be exposed in some form.  Another way to
make the API *feel *simpler is to strongly encourage developers to rely on
the simpler document.hidden, and only use the visibilityState if they have a
specific need for precise knowledge about why the page is hidden.

****
>
>
> PAGE_PRERENDER: Per last week’s call, it appears that the goal with
> prerender is that a web developer shouldn’t take any explicit action for
> prerendering. If a web developer wants to take this scenario into account,
> the developer can still rely on document.hidden – a prerendered page will
> show up as hidden.****
>
> ** **
>
> We do not think that any significant functionality will be lost by removing
> the document.visibilityState.  After removing PAGE_PREVIEW and
> PAGE_PRERENDER, we are left with PAGE_HIDDEN and PAGE_VISIBLE, which is the
> same data that document.hidden provides.****
>
> ** **
>
> As a canonical example of how no functionality is lost, if an ad service
> only delivers advertisements when the user can visually see the ad, in order
> to save system resources in downloading ad resources and rendering the ad,
> this can still be done. On a multi-monitor case, document.hidden will still
> let the web developer know when the user can view the page, and hence, the
> ad should be shown.****
>
> ** **
>
> What are the thoughts on the mailing list in simplifying the Page
> Visibility spec?****
>
> **
>

Although the majority of cases don't require precise knowledge of why the
page is hidden, there are some that do.  As a particular example, removing
the state would make it impossible to factor out prerendering from
client-side impression counts.  Many advertising and analytics packages
today define a page view or impression as when the page loads, irrespective
of if the document is focused or not.  Under that de facto definition, a
load that happens to be in a background tab at page-load time (e.g. opened
by a middle-click) should count as an impression, but a page that prerenders
but is never shown to the user should not.  Without visibilityState, there
is no way to factor our prerenders and maintain the current
semantics--either you can do nothing and count prerenders as views, or you
can factor out *all* hidden pages, including ones that should otherwise be
considered to be a pageview.  The point here is not what an ideal definition
of "pageview" should be for advertising, but rather that the de facto
definition cannot remain if prerendering is possible but visibilityState
does not exist.  You can see an example code snippet at [1] whose semantics
would be impossible to accomplish without visibilityState.

Again, although I'm in support of simplifying the API, I think that it's as
simple as it can get without removing important information.  A superior
alternative to removing visibiltyState, in my mind, is to strongly emphasize
in developer documentation that document.hidden should be used unless
visibilityState is absolutely necessary (even relegating visibilityState to
a footnote if need be).

--Alex

[1] http://code.google.com/chrome/whitepapers/pagevisibility.html