W3C home > Mailing lists > Public > whatwg@whatwg.org > January 2011

[whatwg] Proposal for a tab visibility API

From: Glenn Maynard <glenn@zewt.org>
Date: Tue, 4 Jan 2011 18:50:04 -0500
Message-ID: <AANLkTinKLdLJa6Khqw6iXCtDRuJGjtrZ9Ucme+ijqfvx@mail.gmail.com>
On Tue, Jan 4, 2011 at 6:20 PM, Alex Komoroske <komoroske at chromium.org> wrote:
> 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.

This leaves very little up to the implementation, which might be
overly restrictive.

For example, my alt-tab overlay in Windows might be large, and
entirely cover up a browser window.  The browser would be required to
treat this as "hidden".  That's not necessarily optimal, since it's a
transient state that will go away when the user selects a window.  It
may also be difficult to implement correctly.  It seems like, although
the window is technically not visible, the decision of whether to
treat this as a hidden or visible state should be left to the
browser's discretion.

The earlier condition that I think you mentioned seemed reasonable:
never say the page is "hidden" when it's not, eg. no false positives.
It's more harmful to tell a visible page that it's invisible, than to
tell an invisible page that it's visible:

  * ?visible? : the full-size page content may be at least partially
visible on at least one screen.
  * ?hidden? : the full-size page content is not visible to the user at all.

This gives implementations some latitude to decide whether a condition
should be treated as hidden, and doesn't require figuring out
precisely whether a window is visible in every case.

-- 
Glenn Maynard
Received on Tuesday, 4 January 2011 15:50:04 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:29 UTC