W3C home > Mailing lists > Public > public-web-perf@w3.org > May 2011

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

From: Jatinder Mann <jmann@microsoft.com>
Date: Tue, 31 May 2011 18:18:36 +0000
To: Kyle Simpson <getify@gmail.com>, "public-web-perf@w3.org" <public-web-perf@w3.org>
Message-ID: <EE4C13A1D11CFA49A58343DE361B0B0406859335@TK5EX14MBXC254.redmond.corp.microsoft.com>
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. 

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. 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.

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. 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. Visibility, on the other hand, is simple to define and everyone understands it - your page is either visible or not.

"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.

Even the requestAnimationFrame API, which is designed to deal with drawing and throttling animations, is basing its throttling on the Visibility state. I strongly feel there is value in sharing the Visibility state of the Page with web developers so they can develop more efficient applications.

Jatinder Mann


-----Original Message-----
From: public-web-perf-request@w3.org [mailto:public-web-perf-request@w3.org] On Behalf Of Kyle Simpson
Sent: Monday, May 30, 2011 4:07 PM
To: public-web-perf@w3.org
Subject: Re: [Page Visibility] First Public Working Draft to be Published

I never heard any response to my objection to there even being a "PageVisibility", and my counter-suggestion that the better API would be around "PageIdle".

The more I've thought about PageVisibility as it currently stands, the more I strongly disagree with it. Detecting PageIdle OTOH would be a simpler and more effective approach to getting the same information and accomplishing the same task: throttling down the page's activity when the page is in an unused/inactive state.

--Kyle
Received on Tuesday, 31 May 2011 18:19:04 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 31 May 2011 18:19:05 GMT