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

Re: Proposal for a page visibility API

From: Marcos Caceres <marcosc@opera.com>
Date: Fri, 21 Jan 2011 00:46:39 +0100
Message-ID: <4D38C95F.30803@opera.com>
To: Alex Komoroske <komoroske@chromium.org>
CC: Charles McCathieNevile <chaals@opera.com>, public-webapps@w3.org


On 1/20/11 11:51 AM, Charles McCathieNevile wrote:
> On Thu, 20 Jan 2011 03:22:29 +0100, Alex Komoroske
> <komoroske@chromium.org> wrote:
>
>> Hi all,
>>
>> There is currently no good way for a web page to detect that it is
>> completely invisible to the user...
>
> We have implemented something like this for our extensions framework,
> where it is common to have messaging between a tb and the background tab
> where the main extension logic runs. It would also make sense for
> applications that might want to communicate with each other client-side,
> rather than having to pass everything through a server (not so relevant
> to the common Google models, but very relevant to applications that
> explicitly don't want to share with a cloud provider).
>
>> 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
> * 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...).
>
>> With these use-cases in mind, there are a number of requirements.
>>
>> Requirements
>>
>> * Easy for developers to write scripts that fall back on old behaviors
>> for browsers that do not implement this API
>> * Ability to query the document’s current visibility state
>> * Events fired when the document transitions between visibility states
>> * Ability for browser vendors to add new visibility states in the future

I wonder if view mode media features [1] + CSSOM View's matchMedia() 
method [2] would help meet the requirements? Could looks something like:

var mql = matchMedia("(view-mode:hidden)")
mql.addListener(handleHide)

We would, of course, need to add "hidden" to [1]... but it would not be 
a big deal.

[1] http://dev.w3.org/2006/waf/widgets-vmmf/
[2] http://dev.w3.org/csswg/cssom-view/#dom-window-matchmedia
-- 
Marcos Caceres
Opera Software
Received on Thursday, 20 January 2011 23:47:16 GMT

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