[whatwg] Proposal for a tab visibility API

[Alex Komoroske]

Hi all,

Thanks again for your comments and feedback.  It's been a couple of weeks
since the last activity on this thread, and I wanted to take the opportunity
to do a very high-level summary of the discussion so far and put forward an
updated version of the proposal (which I've included at the end of this
e-mail).

My high-level summary:

Although there is *high *level agreement about the need for a similar type
of API, there are a number of concerns:

1) *Additional potential for abuse*.  My response to this was "Although
there is some additional opportunity for abuse, I think that it is not
particularly large, possible to defend against if necessary, and outweighed
by the advantages such an API would provide to legitimate web developers."
 I'd be interested if those who originally raised this concern agree with
this assessment.
2) *Not the right tool for the use cases*.  Various other proposals,
including an ability to set a timer that only fires when a page is visible
or a way to semantically define what visibility specific types of content
require, have been proposed to address the provided use cases.  So far those
solutions are not concretely defined.
3) *Too specific about tab/window/visibility*.  I've attempted to update the
proposal (pasted below) to be more clear about the specific semantics and
how they might differ on different platforms.  I'd appreciate your comments.

*Updated API proposal*
*
*
document.visibility

A read-only property that returns a string, one of the values described in
the next section.  Developers can use the existence of this property to know
that they can rely on the rest of this API, too.

     Values returned by all conforming implementations
           * “visible” : the full-size page content is at least partially
visible on at least one screen.
           * “hidden” : the full-size page content is not visible to the
user at all.
     Additional values potentially returned by some implementations in some
cases
           * “prerender” : the page is currently being loaded off-screen and
might never be shown to the user.
           * “cache” : the page is currently “frozen” in a cache and not
displayed on screen (e.g. the back-forward cache).
           * “preview” : the page is currently visible only in a
lower-resolution thumbnail.


States in the second set are not guaranteed to be returned in all cases
where they might otherwise appear to apply--it is left to the discretion of
the implementation.

Additional return values may be added to this API in the future.

It is up to the implementation to interpret what these values mean in the
precise context of interface and platform.  As an example, a
current-generation desktop browser might interpret the values the following
way:
    * “visible” : the tab is focused in its non-minimized window (regardless
of the focus state of the containing window).
    * “hidden” : the tab is backgrounded within its window, or the
containing window is minimized.


document.isVisible

A simple convenience read-only property that returns a boolean. Returns true
if document.visibility’s current value is in the set of visibility states
considered to be visible.  In most implementations, only the “visible” state
is considered visible--although some implementations may consider other
values to be visible as well (for example, an implementation that makes
regular use of nearly-full-size thumbnail previews may consider “preview” to
be a visible state).

visibilitychange

A simple event, fired at the document object immediately after
document.visibility transitions between visibility states.  The event has a
property, fromState, that is set to the value of document.visibility just
before it was changed to the current value.  Note that visibility has
nothing to do with whether the document’s contents have fully loaded or not,
which implies that for any given visibility transition event, onload may or
may not have already fired.

On Mon, Dec 20, 2010 at 3:44 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:

> On 12/20/10 5:16 PM, Alex Komoroske wrote:
>
>> But I think overall the discussion about precisely what a tab means is
>> not central to the core proposal.  Is that reasonable?
>>
>
> Yep.
>
> -Boris
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20110104/d380b7dc/attachment.htm>