- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Mon, 27 Jan 2014 14:02:14 -0800
- To: Jatinder Mann <jmann@microsoft.com>, Arvind Jain <arvind@google.com>
- CC: Ojan Vafai <ojan@chromium.org>, Jonas Sicking <jonas@sicking.cc>, "public-web-perf@w3.org" <public-web-perf@w3.org>
On 1/27/14 1:40 PM, Jatinder Mann wrote: > On the compatibility front, one of the principles we used in PVL1 was that we never report something is hidden if it’s truly visible to the user, however, we can error on reporting something is visible when it’s truly hidden if we can’t determine if it’s truly hidden. For example, if my browser window is fully obscured by other application windows, it's truly hidden but PVL1 reports it at as being visible. The idea here is that the user should never have to view the 'hidden' web application experience, but we can tolerate some additional power usage in the background if we can't accurately determine if the web application is truly hidden. I don’t see improving where we wrongly reported something as being visible but was truly hidden to the user, but now can correctly report it correctly as hidden, as a compatibility issue. I see that as improving the accuracy of our results. Does anyone have concerns with this view? This is very much a compatibility issue. For a simple example, http://www.w3.org/TR/vibration/#widl-Navigator-vibrate-boolean-unsigned-long-sequence-unsigned-long--pattern specifies that the API is a no-op if document.hidden is true. So right now that API works in a display:none iframe (whether it _should_ is a separate concern), but if the definition of "hidden" is changed it would stop working. Unless the Vibration API spec continues to specifically reference the PVL1 definition, not the PVL2 one or something... -Boris
Received on Monday, 27 January 2014 22:02:45 UTC