[whatwg] Proposal for a tab visibility API
dennis at efjot.de
Fri Dec 10 04:14:58 PST 2010
Am 08.12.2010, 23:09 Uhr, schrieb Aryeh Gregor <Simetrical+w3c at gmail.com>:
> On Wed, Dec 8, 2010 at 2:47 PM, Alex Komoroske <komoroske at chromium.org>
>> 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?
Maybe we can disallow the "visibilitychange" event to produce any dialogs
or anything else that could give focus?
More information about the whatwg