Re: [Page Visibility] Spec Updates

> Those situations are all "visible".

I rather disagree, specifically on two cases: "window fully off screen" and 
"window fully obscured by any other window or OS display, but still 
active"... for instance, in windows, if a window is active in Windows OS, 
and the user hits ctrl+alt+del to bring up the lock/logoff dialog, I believe 
the window is probably still considered active, but it's clearly not 
visible, and should probably cycle down it's activity.

If we call this state "hidden", but we don't even define such a clearly 
"hidden" state as those two above, then I think the state is misnamed. If 
the key trait is not visible/hidden, but visible+active/invisible+inactive, 
then we should come up with a name that indicates that semantically. From my 
readings, I expected such cases as "window entirely off screen" and "window 
still active but covered up by some other window" to in fact be "hidden". So 
I think as things stand, it's rather confusing.


>> --------------
>> In the spirit of this type of functionality, should there be a PAGE_IDLE 
>> type of state/event?
>
> That seems orthogonal.

First off, that's why I added the "--------" separator and worded my 
question the way I did...

But, more importantly, I think it's orthagonal only from one perspective (in 
the sense of it being an additional suggestion), but in another (and the one 
I have in mind currently) perspective, it's actually quite related.

My reasoning, from a performance perspective, is that perhaps the more 
appropriate "hook" we should be looking at is idleness rather than 
visibility. As someone who spends a great deal of time obsessing about how 
to optimize performance, the much more important factor that I'd use to 
decide if I should switch a site into low-performance mode, like slowing 
down polling timers, shutting off animations, etc, would be if the page is 
idle for a certain period of time.

For instance, if I was going to stop animations when the page was hidden, 
and let's just pretend there's some non-trivial amount of work to do to shut 
off an animation (not just pause it, but hide or reset some element's 
position/orientation), then I definitely would want some sort of de-bouncing 
so that I didn't just stop the animation if the window fired the state 
"hidden" and then 10ms later went back to "visible".

If the need for debouncing is, in principle, something that can be seen as 
being generally applicable to some or many of these use-cases, to prevent 
the very quick/intermittent state changes that can happen as a user 
navigates their desktop or mobile device, then I think that makes a case 
that "IDLE" is the more important trigger than "HIDDEN", because "IDLE" 
implies a time interval.

Also, I think if we re-think things in terms of "idleness" rather than 
"visibility", a bunch of the corner cases I've been talking about (in this 
thread and previous ones) are really quite moot. `IDLE` seems like a good 
simplification of the mechanism in question, while still in spirit honoring 
what we, as a web performance group, are trying to provide: a signal to the 
page that the user isn't actively using the site at that time, and so that's 
a hint that it should perhaps consider throttling or suspending it's normal 
activities.

Lastly, I think that the concept of IDLE should be a user-subscribable 
thing... like for instance `window.setOnIdle(callback,idle_timeout)`, rather 
than necessarily a fixed timeout that the browser controls. That relieves 
any potential inflexibility arguments by making it "user-configurable" (of 
sorts). Alternatively, the `timeout` parameter could be optional, with a 
default that the browser decides itself, and the user JavaScript can 
override it if they want "idle" notifications more or less often than the 
default.


--Kyle

Received on Saturday, 14 May 2011 01:19:50 UTC