[whatwg] Proposal for a tab visibility API

Aryeh Gregor Simetrical+w3c at gmail.com
Wed Dec 8 14:09:44 PST 2010


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?



More information about the whatwg mailing list