[whatwg] Proposal for a tab visibility API

[Alex Komoroske]

Hi Bjartur,

Thanks for your comments.  My responses are inline.

On Mon, Dec 20, 2010 at 8:56 PM, Bjartur Thorlacius <svartman95 at gmail.com>wrote:

> On 12/20/10, Alex Komoroske <komoroske at chromium.org> wrote:
> > Thanks for your comments.  I've replied inline.
> >
> > On Sun, Dec 19, 2010 at 8:11 PM, Bjartur Thorlacius
> > <svartman95 at gmail.com>wrote:
> >
> >> On Wed, 15 Dec 2010 19:27:51 -0000, Alex Komoroske
> >> <komoroske at chromium.org> wrote:
> >>
> >>> Regarding the fact that background tabs aren't necessarily invisible:
> >>> -----
> >>>
> >>>  On December 8, Boris Zbarsky wrote:
> >>>>
> >>>
> >>> There is no such guarantee for background tabs.  For example, browsers
> >>> may
> >>>
> >>>> show tab previews in various contexts (Panorama in Firefox 4, e.g.).
> >>>>
> >>>
> >>> -----
> >>>
> >>> The point of the API, as proposed, is that page scripts will know when
> >>> their
> >>> content is guaranteed to be invisible to the user--that is, the API
> will
> >>> not
> >>> provide a false positive about invisibility.  However, the API may
> >>> provide
> >>> false negatives about invisibility, for reasons many others on this
> >>> thread
> >>> have been pointed out (including different windowing systems, multiple
> >>> monitors, partial transparency, etc.).
> >>>
> >>> The easiest way to achieve this guarantee is to only consider a tab
> >>> hidden
> >>> when it is a background tab within* *a window.  The window itself, of
> >>> course, may be on a little-noticed second monitor, partially obscured,
> >>> etc.
> The obvious way to achieve this is to only consider a tab/window hidden
> when
> it's not on-screen, and consider it visible when it's on-screen. What good
> is
> being the current tab when the window is off-screen?
>
>
> >> I don´t see how that information is useful.  Now, you have to define
> >> 'window'
> >> and 'tab' differently and define a background state of the latter. Do
> >> multiple
> >> non-backgrounded (attached) tabs in a window need special treatment? If
> >> you use the term 'tab' anywhere it _will_ be confused with the UI
> >> metaphor,
> >> causing confusion with the approach to hierarchical window management.
> >> I don't understand what the term 'tab' means to you. To me a tab is a
> >> window.
> >
> >
> > I'm not sure that I understand the point of confusion.  When I say 'tab',
> I
> > mean the current UI construct implemented in Firefox, Safari, Chrome,
> Opera,
> > Internet Explorer, and others.  Each window can have one or more tabs,
> and
> > in curent implementations (with very few exceptions), each window can
> only
> > have a single visible tab.
> >
> In context of many of the less-widely used browsers the word 'tab' is
> never used.
> Each top-level browsing context has an associated window, which may be
> grouped with other windows and that group may be represented as a tab
> strip,
> wherefrom windows may be selected. They may also be tiled, and a tab strip
> which allows multiple windows to be selected (tabbed desktops), causing
> them
> to tile. How does your proposal work wrt tagged windows (as used in wmii,
> dwm)?
>
> I don't understand an UI construct used by WMs is of any interest to
> applications.
> AFAIK, X11 only notifies clients about changing visibility, and by
> extension,
> partial overlaps. Why would apps rather know whether they're selected in a
> tab
> strip (creating an unnecessary requirement for tab strips) than whether
> they're
> visible? With the aforementioned WMs (wmii, dwm) windows may be in multiple
> groups (tags). In wmii, windows are managed hierarchically. This isn't of
> any
> concern to anyone but the user. Applications shouldn't care at all.
> They're given a
> resizing window of variable visibility to draw on; tabs don't matter.
>

Thanks for the clarification.  I attempted to address this in the e-mail I
just sent in response to Boris.  (In a nutshell: I agree with you about tabs
not being a central UI concept, but I think that the concept of "tab" is not
core to the proposal.)  Let me know if that e-mail doesn't address these
concerns.

>
> > I'm not sure that I have seen your counterproposal.  Based on your
> comments
> > in this thread, I presume that it includes an ability for pages to
> declare
> > what capabilities they require (e.g. an animation requires that it be
> > visible) and then the browser automatically pauses scripts when those
> > required conditions are not met.  Is that a proper understanding of your
> > counterproposal?  Is there a more comprehensive/detailed version of the
> > proposal that I could read and comment on?
> >
> Yes, your understanding is correct, and no, there is none.
>
>
> >>>  On December 8th, Maciej Stachowiak wrote:
> >>>> This use case can be handled without help from the page. In Safari,
> >>>> video
> >>>> (whether through media elements or plugins) won't start playing when a
> >>>> user
> >>>> opens a tab in the background, until the user switches to that tab.
> >>>>
> >>>
> >>> -----
> >>>
> >>> Although what you describe satisfies the specific use case, it doesn't
> >>> address the more general use case of animations (either explicit via
> >>> javascript or via CSS Animations) or content that is not a plugin/video
> >>> file.
> >>>
> Modularity is good.
>
> >>>  I argue that there are two potentially viable solutions:
> Implementations
> >> exploiting more methods á la Safari, stopping animations or apps
> declaring
> >> dependencies on various things like visibility and audibility. There are
> >> previous proposals regarding throwing CSS media events upon change,
> which
> >> could potentially be integrated with this.
> >>
> >> The whole things smells of over-engineering. A resource of MIME media
> type
> >> "audio" obviously can't be rendered without audibility, "image"
> resources
> >> sans (2D) visibility nor "model" resources sans 3D visibility. "Text"
> >> resources can be rendered both visually and aurally, and "model"s can
> also
> >> be rendered to 2D displays, as long they're interactive (they're
> >> redrawable
> >> and user input is accessible).
> >
> >
> > Although I agree that in some limited cases the correct behavior is
> clear,
> > in practice there is a lot of gray area for many common cases.  A
> multi-user
> > collaborative puzzle should continue executing even when in the
> background
> > (perhaps another player made a move that should play a sound to alert
> this
> > user of the new move); a single-player puzzle might not need to execute
> at
> > all when backgrounded.  The more complex the web app, the more likely
> that
> > the precise needs for pausing can't be met precisely with simple
> "semantic"
> > directives to the browser.
> >
> A multiplayer puzzle needs either focus and visibility (and'll use a
> network
> connection when available) or a network connection and a notification
> mechanism. The developer will be aware of what interfaces the app utilizes,
> and
> declaring dependencies on interfaces he might otherwise take for granted
> might,
> as a surplus, prompt him to think about accessibility issues that may rise
> when
> the interfaces can't be used.
>

I agree that the notion of visibility is perhaps an imperfect proxy for what
the developer really wants to know.  However, I believe that in practice
it's a reasonably powerful proxy, and that the alternative--designing a
system to let the developer precisely define the interfaces he requires, in
many different contexts--is quite a larger undertaking.


>
> >
> >>
> >>
> >>  Regarding solving the use cases that cannot be addressed currently:
> >>> ------
> >>> On December 8th, Maciej Stachowiak wrote:
> >>>
> >>> That leaves the following use cases:
> >>> * 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.
> >>>
> >> The counter is paused while the script's suspended, wall-clock keeps
> >> going.
> >>
> >>  * A web app that uses polling to fetch dynamic content can pause
> polling
> >>> when it knows the page is hidden from the user.
> >>>
> >> A suspended script can't phone home.
> >>
> >>  * A page wants to detect when it is being prerendered so it can behave
> >>> appropriately.
> >>>
> >> The only use case for this I can see is confusing users. That's probably
> >> just me.
> >
> >
> > I'm not sure that I understand this point.  Given the existence of a
> > pre-rendering feature, how would providing information to the page about
> > whether it is being pre-rendered lead to confusion of users?
> >
> My misunderstanding. It cannot cause user-confusion. Ignore.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20101220/d023f373/attachment-0002.htm>