Re: Proposal for a page visibility API

On Thu, Jan 20, 2011 at 2:02 AM, Glenn Maynard <glenn@zewt.org> wrote:

> On Wed, Jan 19, 2011 at 9:22 PM, Alex Komoroske <komoroske@chromium.org>wrote:
>>
>> Use cases
>>
>> * A page wants to detect when it is being prerendered so it can behave
>> appropriately.
>> * A puzzle game has a timer that keeps track of how long the user has
>> taken to solve the puzzle.  It wants to pause the timer when the user has
>> hidden the tab.
>> * A web app that uses polling to fetch dynamic content can pause polling
>> when it knows the page is hidden from the user.
>> * A streaming video site doesn’t want to start the video until the user
>> actually views the tab for the first time (i.e. video shouldn’t start
>> automatically if a user opens the tab in the background).
>>
>
> Another example of this use case: a browser session is restored with many
> tabs.  As with loading a link in a background tab, video shouldn't start
> playing.  I've lost count of the number of times I've reloaded my browser
> and had a YouTube video or three start playing (somewhere among my three
> browser windows and around 60-80 tabs).
>
> Note that the Flash videos on http://www.ted.com do load paused if they're
> loaded in the background, which is very helpful; I can middle-click lots of
> videos in the video index into background tabs, and then view them one at a
> time.  It should be possible to implement this for HTML5 video.
>
> The same applies to anything that plays sound, like games--they shouldn't
> start immediately when they're in a background tab on load.
>

Agreed, these are common and valuable use cases.

>
> * Values returned by all conforming implementations
>>     * “visible” : the full-size page content may be at least partially
>> visible on at least one screen.
>>
>
> More simply, "the full-size page content may be at least partially
> visible".
>

Agreed.  Changed.

>
>     * “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.
>>
>
> I think that at least visible and hidden should be explicitly defined as
> having document.visible true and false, not technically left
> implementation-defined.  Defining "prerender" and "cache" as false is
> probably good too, if their descriptions specifically say "off-screen".
>

Agreed, and changed.

>
> If you intend "preview" to include large but smaller-than-full-size
> previews, eg. scaled to 50%, I'd recommend avoiding the word "thumbnail"; I
> think most people wouldn't consider that a thumbnail.  (I could probably
> come up with a reasonable UI where a preview is at 100%, too...)
>

I agree, although I'm struggling with the precise wording to replace that
description with.  Do you have any suggestions?

>
> > visibilitychange
> >
> > A simple event, fired at the document object immediately after
> document.visibilityState transitions between visibility states.  The event
> has a property, fromState, that is set to the value of
> document.visibilityState 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.
>
> This should also include the old document.visibility value.
>

Agreed, but what should the property of the event be called?  fromVisible
seems awkward.

>
> Thoughts and comments are welcome.
>>
>
> I think is very important information to make available to scripts.
>

Just to make my agreement complete, I'll point out that I agree about this,
as well. :-)

>
> --
> Glenn Maynard
>