Re: [Page Visibility] First Public Working Draft to be Published

> Based on your description, it appears that you are defining IDLE as the 
> state in which the user has not interacted with the page for a given 
> amount of time.

Yes. Or, more precisely, when no user-initiated events have happened 
anywhere on the page for a given amount of time.


> The only scenario where IDLE would behave differently from Visibility 
> appears to be the case where the browser is in the foreground, but the 
> user is actively interacting with another application.

I disagree with this assertion. IDLE would behave differently from 
VISIBILITY in all cases, because IDLE would have, by its very definition, 
debouncing built into it. This is not a trivial distinction, it's a 
fundamental, and important, difference.


> For example, a user could be viewing a web based email application or a 
> video in their browser, but actively interacting with another application. 
> The browser state here would be defined as IDLE - even though the page is 
> entirely visible, the page may incorrectly throttle down email checks or 
> pause the video. Here IDLE state gives the wrong behavior, whereas 
> Visibility gives the expected behavior.

On the contrary, as a web developer by trade, I can say that this is 
precisely the type of scenario where I can see it actually being useful to 
throttle down activity. Now, there's obviously the question of if the user 
*wants* a page to do that or not, and sites would probably be ill-advised to 
do anything of this sort (automatically without opt-in), especially on 
desktops as opposed to on resource limited mobile devices (for battery life, 
metered bandwidth consumption, etc).

But again, as a web developer who cares about optimizing performance as it 
impacts device resource consumption, the ACTUAL thing that I want to key off 
of is IDLEness.... thus using "visibility states" is just a poor inferior 
substitute, and (as I've said in several other threads) adds more complexity 
than its worth (all the niche cases of what really is fully "visible" or 
not). With IDLE, the page is either idle or it's not-idle. Yes, the question 
of timing comes into play, but this I see as actually *quite valuable* to 
allow the page author to control that setting.

The authors don't get to define what IDLE means, the spec does ("no mouse, 
keyboard, or any other user-initiated events"), but they *do* get to control 
the sensitivity level. This means they can decide to be more sensitive to 
IDLEness on mobile devices, and less sensitive on more powerful desktops, 
etc. That allows for a much wider range of flexibility in performance 
optimization than does "visibility states".

As a web dev with much interest in web optimization, I can say unequivocally 
that the "page visibility" spec as it stands now is not something I'd use at 
all, and I'd in fact encourage others not to do so, as I think it's bad 
practice and sets bad precedent. OTOH, a simple and direct IDLEness API 
would be extremely useful for this type of optimization.

I am not making these assertions lightly. I've gone and thought about this 
(after registering my objections and questions awhile back), and the more 
I've thought about it and explored how I would use it in my existing sites, 
the more I'm convinced that VISIBILITY is inferior to IDLE.


> Who defines the amount of time for when the page is to be considered IDLE? 
> Expecting a user to change a browser setting to set their ideal IDLE time 
> seems cumbersome. Likewise, expecting web developers to choose the IDLE 
> times may lead to large inconsistencies in what is considered IDLE.

I said already that the timeout interval would have a UA-defined default (if 
the author doesn't specify one), but be controllable by the author.

"large inconsistencies"? If anything about web performance optimization is 
true, it's that one rule rarely fits all sites. By having a rigid and 
complex "visibility states" spec, we handcuff authors that they can only key 
off these rather confusing page visibility states, and if they want to do 
anything smarter (like debouncing or delaying reaction), they have to 
engineer it themselves, in an inferior way.

By contrast, giving them a more flexible mechanism where they can directly 
control the sensitivity allows a web author to apply more sophisticated (and 
thus more likely to be optimal) rules of optimization to different sites, 
and indeed to the same site viewed on different devices.


> Defining an algorithm for IDLE isn't easy, as browsers may not uniformly 
> implement the algorithm defined in the spec or that algorithm may not be 
> consistent with how other applications define it.

Huh? The definition of what is IDLE is very simple and requires only a basic 
knowledge of computers to understand: no user-initiated events (mouse, 
keyboard, etc) in a certain time frame. Period. End of definition. I can't 
see how it could get any more simple than that?

Also, if we are already conceeding that UAs are not going to implement what 
we spec, then all this effort is for naught. I think we have to assume good 
faith, that if we give them a simple definition, they'll implement it as 
such. Shouldn't we be slow to assume the worst about the UAs?


> Visibility, on the other hand, is simple to define and everyone 
> understands it - your page is either visible or not.

Absolutely not, it's not simple. See all the questions I raised in previous 
threads. I'm a reasonably intelligent and experienced developer, and I 
still, after having read it several times, and engaged in discussions on 
this list and on the phone calls, don't quite understand how to navigate it 
clearly. It's confusing enough that I simply wouldn't use it, and as I said, 
I'd recommend the same to others.

I noted in the previous thread several cases where we say something is "NOT 
VISIBLE", but in fact what we really mean is "NOT VISIBLE **AND** NOT 
ACTIVE". Having these hidden semantics not exposed in the names of the 
states is quite confusing. Also, the exceptions that were made for 
full-screen overlays such as A11Y tools -- I think it's all just a mess.

As I said above, I think "PAGE VISIBILITY" is fatally flawed in that it's 
indirectly (and confusingly) trying to expose what a developer really wants 
to key off of. When it comes down to it, a performance architect doesn't 
care whether a page is visible or not so much as they care whether the page 
is being used actively or not. If it's IDLE (not being used at the moment) 
that's the case when we want to consider throttling down our activity.

This seems so self-obvious to me that IDLE is what we really are going 
after, not VISIBILITY. I'm having trouble understanding why you don't see 
that the same. Can you explain why a developer would care *more* about the 
visibility of a page than about its interactivity level, in terms of how to 
optimize said page? I honestly can't come up with any plausible reasoning.

As an example, consider the case of pages (like the one I'm currently 
listening to) which do nothing but stream audio (internet radio). VISIBILITY 
means absolutely nothing on such a page, as there's basically no visual 
component to a radio player. IF that site were going to try to key off of 
anything, they wouldn't key off of if I have the page minimized in the 
background, they'd key off of how long it'd been since I interacted with the 
page.

And in fact, that's EXACTLY what they do... they have their own timeout 
system, where they wait awhile, then they try to ping me on the page to see 
if I'm still around. If not, and I don't respond in a short window, then 
they turn off the stream. This is EXACTLY the mentality that I'm suggesting, 
and it's entirely based on my level of interactivity (non-IDLEness) with a 
page, not at all how visible or invisible the page is.


> "De-bouncing" overhead shouldn't be a problem - that's like saying basing 
> your game's state on the user's mouse movement will cause problems. For 
> visibility events to be fired at the same rate as mouse events is 
> unlikely, and most probably, impossible for a user to do.

It's extremely easy for me to cycle a window through various "preview" modes 
in windows quite quickly, using the task back with my mouse moving, or by 
holding down alt+tab and cycling through the apps, etc.

The point I was making with debouncing is that any author that's going to 
implement this VISIBILITY in a real production app with any wisdom is going 
to have to architect their own debouncing on top of it. By contrast, we 
could drastically simplify how easy it is to use this functionality if the 
API had debouncing built into its definition, by keying off IDLE instead of 
VISIBLE.


> I strongly feel there is value in sharing the Visibility state of the Page 
> with web developers so they can develop more efficient applications.

I just as strongly feel that giving them VISIBILITY when what they really 
need is IDLE is a mistake -- it's like giving a dog a carrot stick when what 
he really wants is a bone. But I equally strongly feel that IDLE would be a 
very useful performance optimization feature to expose to authors, and I'd 
fully support and endorse such a feature.

We're not arguing about the spirit of the effort, we're arguing about the 
means. And, with all due respect, I think the means you're pushing is 
misdirected and inappropriate for web devs and performance optimization 
engineers, and I say that as one who operates daily in those trenches.


--Kyle

Received on Tuesday, 31 May 2011 19:39:44 UTC