W3C home > Mailing lists > Public > whatwg@whatwg.org > December 2010

[whatwg] Proposal for a tab visibility API

From: Aryeh Gregor <Simetrical+w3c@gmail.com>
Date: Wed, 8 Dec 2010 17:09:44 -0500
Message-ID: <AANLkTimAPDd7Vdinhy+rPER=RCpLYMmD5MpJSdano0yy@mail.gmail.com>
On Wed, Dec 8, 2010 at 2:47 PM, Alex Komoroske <komoroske at chromium.org> wrote:
> =visibilitychanged=
> A simple event, fired at the document object immediately after
> document.visibility transitions between visibility states.

Should be "visibilitychange" rather than "visibilitychanged", to match
"change", "cuechange", "durationchange", "formchange", "ratechange",
"readystatechange", and "volumechange" (I didn't expect so many . .
.).

On Wed, Dec 8, 2010 at 2:57 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> 2)  There is some potential for abuse (e.g. putting up dialogs to make
>    yourself the active tab if you determine that you aren't, though
>    perhaps this is a quality of implementation issue).  I can
>    particularly see things like ads doing this so you don't just
>    switch to a different tab while they're running.

That sounds like it would probably eclipse all other use-cases in
popularity.  More sites have ads with timers on them than contain
puzzle games or poll for dynamic content.  Is there any way for
browsers to dodge this while still serving the other use-cases?  Or do
we just figure that users can just leave the site or do per-site
blocking if it gets too annoying, so it's not a big problem?
Received on Wednesday, 8 December 2010 14:09:44 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:02 UTC