W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2011

Re: Proposal for a page visibility API

From: Alex Komoroske <komoroske@chromium.org>
Date: Thu, 20 Jan 2011 12:04:07 -0800
Message-ID: <AANLkTi=Vvmc=C1pUa7eHAZbWBAHMBwU75bFFUJTrFh+O@mail.gmail.com>
To: Charles McCathieNevile <chaals@opera.com>
Cc: public-webapps@w3.org
On Thu, Jan 20, 2011 at 2:51 AM, Charles McCathieNevile <chaals@opera.com>wrote:

> On Thu, 20 Jan 2011 03:22:29 +0100, Alex Komoroske <komoroske@chromium.org>
> wrote:
>
>  Use cases
>>
>
> * An app can provide notifications (using the Web Notification stuff that
> is under developemnt) when it is not visible/focused, but skip them when it
> is to minimise distractions and reduce cognitive load
>

Great use case, I'll add this to the list.


> * An application can (try to) communicate with the currently focused
> application. This is essentially what a whole class of extensions does in
> practice. Enabling it for general HTML would be a step towards making it
> possible to share different functionality extensions. Right now, it would
> rely on out-of-band agreement about how to communicate, but that is
> perfectly feasible in practice. It also introduces a clear requirement for a
> security discussion (see the paper that Art posted recently...).


Although I think this is an interesting and valid use case (and one, as you
point out, that has many examples in practice today), I think it has the
potential to complicate this proposal, especially regarding security (again,
as you note).  Is there a way to design this API in a way that makes the
additional functionality fit in better in some future proposal?

>
>
> The idea that a thumbnail, or popup, can mean that more than one document
> is visible is interesting.
>

Agreed.  The bulk of the discussion on the what-wg list centered around
what, precisely, it meant to be visible.  We identified a number of
interesting cases, like the preview features that some browsers implement
today.  Other complexities include multiple screens and windows that are
partially or completely obscured by other windows.  That led to the current
wording of this proposal, which is deliberately somewhat vague and
interface-concept agnostic, and only provides a strong guarantee that, if
the API says you're hidden, you are definitely hidden.  (However, note that
it is possible for the API to report that you're visible when in practice
you aren't, e.g. when your window is completely obscured by another window.)

>
> In our API we have getFocused() (which mostly does what it says on the box,
> although certain special tabs don't respond to it)
>
>
>  document.visibilityState
>>
>> A read-only property that returns a string
>>
>
> It would make sense to have this relate to the ViewModes stuff that was
> originally developed for widgets, no?


Based on my reading of the view-modes in the widgets spec, I don't think
they relate particularly closely.  View-mode seems to be a request from the
app for a specific type of display, whereas this API proposes a way for a
page to query its visibility but not request a change in visibility.   Also
note that the specific UI concepts of "fullscreen", "windowed", etc are
deliberately avoided by this API for the reasons that I referenced above
from the what-wg thread.
Received on Thursday, 20 January 2011 20:04:59 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:43 GMT