RE: Further concerns with PageVisibility

You have made incorrect assumptions, like the definition of Page Visibility includes the activity state of a page. It does not.

As discussed in the conference call today, in order to converge on decisions and avoid reiterating over issues that were thought to be closed, please open issues on the spec via the Web Perf issue tracker, http://www.w3.org/2010/webperf/track/issues. This will both help document our decisions and help the specifications converge.

Thanks,
Jatinder

-----Original Message-----
From: Kyle Simpson [mailto:getify@gmail.com] 
Sent: Wednesday, June 15, 2011 1:12 PM
To: public-web-perf@w3.org
Cc: Jatinder Mann
Subject: Re: Further concerns with PageVisibility

>> 1. confusions of the various conditions under which a window goes 
>> through visible (and partially visible) states in various OS's and 
>> devices
>
> As we have discussed on the mailing list and the conference calls, 
> this specification defines Page Visibility in a platform agnostic 
> manner. The definitions of Page Visibility must be generic enough that 
> they will work across platforms.

While the spec may be taking great pains to be platform-agnostic, my concerns are primarily about how I see this playing out in an implementation-specific way. It's the difference between theory and practice.

I think PageVisibility is setting confusing traps where implementations will have a lot more complications to deal with. What this means to me as a developer is that I'll have more cases where a browser ends up deciding to do something undesirable, then I'll have to file bugs with that browser to get them to change it, blah blah blah. I want to avoid such traps *wherever* possible.

One way to avoid such traps is for a spec to be absolutely clear and unambiguous. In this case, I think you'd agree that this is not only undesirable, but impractical.

The other way is to avoid an API that sets such traps, for instance, a simpler API (that still fills all the use-cases) with not only fewer states, but much less ambiguity of exactly which state a browser can be in.

The nature of layered windowing systems, as they exist across hundreds of different device+OS combinations, is asking for each particular combination to have to go through a lot of usability testing to find out exactly which side of the ambiguities they should come down on.


> >> 2. It lacks the "de-bouncing" inherently required to effectively 
> >> work with it as a "throttling" trigger for various activities 
> >> (meaning we'll have to manually author setTimeout type de-bouncing every time).
>
> "de-bouncing" may be a concern in the preview cycling scenario

That's one case, yes, but there are others. For instance, if I have two browser windows open, both inactive but "visible", and they're layered on top of each other in such a way that I could accidentally click one to activate it, but mean to click the other (this happens all the time for people like me who use many tiled windows). If I click the wrong one, and "immediately" correct my mistake and click the other, I'll cause the incorrectly clicked on page to become "visible" for a split second and then "invisible" again.

Another example (again, quite common for me), is having multiple instances of a browser window open, where my windows taskbar has a list of all of them available by clicking the grouped task-bar entry. I see the "menu" (of
sorts) of each instance... but it's not always clear exactly which one is the one I want to open (if the titles are ambiguous or unclear), and so I regularly will accidentally click one, and then very quickly realize I clicked the wrong one, and switch (sometimes with a quick alt+tab keystroke). Again, this will fire a very quick succession of "visible" and then "invisible" states.

In both those scenarios, and several others I could construct, the rapid succession of "visible"->"invisible" (or "invisible"->"preview" or
"visible"->"preview") state changes *MUST* be something that I, as a web developer, take into account if I'm ever going to implement such behavior on a page. It would be quite ignorant to just blindly listen for the "visible", "preview" and "invisible" state changes and not at all pay attention to how close in proximity they fire.

So, in almost any use-case I can construct for such an throttling API in my JavaScript, I would almost always have a minimum de-bounce time of say 200-400ms, where I would not respond to an event (a state change) until I was reasonably sure that the state I arrived at was stable (at least for "now").

Can you give me counter-examples where de-bouncing (in the rapid state change scenarios I described) would be overkill or irrelevant, for the throttling performance concerns?


> "de-bouncing" protection... can be added by the web developer using 
> the Page Visibility API.

I maintain that almost all responsible uses of this API will, in practice, need to have some sort of debouncing intelligence built-in. Developers may start out with the assumption of just subscribing to the event, but I think as they hone the behavior of their page and go through more extensive testing or user-feedback, in most cases they'll wind up needing to add at least some fashion of de-bouncing, if nothing than to account for users like me.

For instance, imagine a page fires off an XHR on every state change... and imagine I as a user am prone to this mistaken browser activation quite frequently... a server admin will see the clogged log full of patterns of a bunch of "visible"/"invisible" pairs of requests, and he'll probably tell the developer to figure out how to reduce those things. How will that developer do that? Debouncing.


> (if the scenario even needs it)
> ... Microsoft firmly supports creating a Page Visibility API...

I think you may be listening more to browser vendors' requests for this API than you are considering how real-world web developers will have to interact with it.

I have a long career of experience as a web developer, and my strong instinct is that this API will be one that developers eventually realize has such rough edges and they'll wish it wasn't so. I think it's healthy for us to consider such things now, before we're so locked into the API that changing it is impractical.

If it's a choice between what browser vendors want/need, and what web developers want/need, we should make sure we're giving a lot more weight to the developers' concerns. I'm speaking as a developer, and I feel like you're not giving much credence to my concerns.


> User Idle.... Page Visibility gives a web developer a means to 
> programmatically determine if the Page is not visible and throttle 
> down page activity and resources. These are two separate and 
> complimentary APIs.

There's far more overlap between them then you are giving credit to. Namely, almost the entire set of use-cases for PageVisibility can be handled by PageIdle, whereas PageIdle (with debouncing built in) cannot be replaced by PageVisibility by itself, because debouncing must (often) be implemented on top of it.

I think if you were to have a dialogue with web developers who would consider "throttling" a page's activity down under certain circumstances, they would probably tend to initially say "well, I'd throttle it down when the page is not visible".

BUT, if you dig any deeper in such conversations, I think most developers would come to realize that when they are saying "when the page is invisible", what they really *mean* is "when the page is inactive/idle".

This is what I mean by saying that "PageVisibility" is a half-implementation of PageIdle, because I think on critical examination, most people who say that "visibility" is the trigger probably intend for "(in)activity" to be the real trigger.

Do you have any evidence to suggest that this analysis is baseless or irrelevant?


> The definition of "autoplay" will not change due to Page Visibility. If a 
> developer doesn't want to auto play a video, the "autoplay" attribute 
> should not be used on the video element. Instead, the developer should 
> check for visibility, and accordingly play the video.

I wasn't asking if "autoplay" will change due to Page Visibility. I was 
asking if "autoplay" will change as a result of a page being in the 
"prerendered" state, in the way that Chrome is now experimenting with. It's 
quite clear that "prerendering" as a functionality requires some sort of 
flag to indicate the state (for pages who want to opt-out, if nothing else), 
which is why PageVisibility is a necessary component.

If it is determined that the "prerendered" state (and thus the prerendering 
itself) creates problems for facilities such as "autoplay" or "autofocus", 
then I think it absolutely is something that we should be discussing as it 
relates to PageVisibility (since that affects one of its states).

How ridiculous would it be if I visit page A, and a few seconds later I hear 
some audio playing in the background, and it's because the browser 
prerendered (and started autoplay playing) audio/video on page B, which I 
haven't even visited yet. That'd be absurd. So implementations are going to 
have to address this issue.

If a browser chooses to resolve this problem by simply delaying all such 
behaviors until the first "visible" state is fired, then it ABSOLUTELY 
matters that we have to be clear and crisp in the definition of 
"prerendered" state what that actually means, and also that we call out the 
special nature of only the first "visible" state change.

If we're providing an interface for JavaScript developers to do special 
behavior (during a certain state like the "prerendered", or upon a special 
state change like "prerendered" to "visible"), then we have to tell them 
what that means, exactly and specifically. In other words, that state means 
X and Y, but doesn't mean Z.

If one browser delays autoplay playing until first "visible" state, but 
another browser doesn't, this will wreak havoc on JavaScript developers who 
rely on such things, especially since that quirk of behavior will be 
completely non-featuretestable.

If we leave what all that means up to implementations, then we'll create a 
confusing and untenable API for most developers, and create even more 
"traps" (like I said above) that I think we could and should avoid.


> Page Visibility is not being kept because of prerender - Page Visibility 
> is designed, as I have stated prior, because there is value in providing 
> the visibility information to developers.

Respectfully, I think you missed the subtlety of my wording. Kept vs. 
designed. I understand the original design as being more broad (and gave 
credit to it).

But, in our discussions (list, phone, etc), I've repeatedly asked for any 
example/use-case where PageVisibility more completely addresses a use-case 
that a PageIdle API would not. In other words, is there any reason why 
"visibility" is a more important/useful trigger for throttling than 
idleness? Or, is there anything that visibility gives us which idleness does 
not?

The *only* example given that had any credibility was the prerendering, 
which I readily admit is not addressed by PageIdle.

So, in my mind, insisting on keeping PageVisibility (which is more 
complicated and has unresolved questions to it) in addition to a possible 
future PageIdle, instead of even *considering* (you have flatly rejected 
this as a possibility) that PageIdle could be a valid and simpler 
*replacement*, is based in significant part on the fact that PageIdle 
doesn't address the prerendering functionality that vendor(s) are asking 
for.

I understand that you've asserted that the two are complimentary APIs, but I 
do not see them as such, nor have I seen any discussion which actually 
supports that in a plausible way. If you suggest they are complimentary, 
then you have to identify how the two are different in co-equally useful 
ways. Almost all the usefulness of PageVisibility is covered by PageIdle, so 
the co-equally different stuff is rather hard to find.

I renew my standing question: if PageVisibility had not already been 
"adopted", and we were still in the design phase, is there any solid reason 
(*besides prerendering*) why PageVisibility would be better than (or needs 
to exist in addition to) a PageIdle?

If there isn't a valid argument for visibility over/in-addition-to idle, 
then I submit to you that you're keeping visibility primarily because of 
prerendering, specifically.



--Kyle

Received on Wednesday, 15 June 2011 23:09:16 UTC