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. For example, the specification should not call out features of a specific operating system, e.g., Page Preview, Taskbar Preview or Aero Peek on Windows 7. It should instead define the states in a generic platform independent manner. Spec is defined such that user agents must definitely state when the page is hidden, but give best effort to state when the page is visible.

> 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 (e.g., holding down ALT-TAB or Window-TAB on Windows 7). For example, on Windows 7, if Internet Explorer is not minimized and you cycle through the previews, you will see dynamic/active content. However, since the browser is not minimized, the visibility state will already be visible, not preview. If IE is minimized and you cycle through the previews, you will not get dynamic/active content, and the visibility will be reported as hidden. So at least on Windows, preview cycle does not impact visibility state and your debouncing concern doesn't exist.

If another platform implements preview cycling in a way that causes many state changes, "de-bouncing" protection (if the scenario even needs it) can be added by the web developer using the Page Visibility API.

> 3. That this interface basically looks like a half-attempt at a PageIdle API, which would serve all use-cases of PageVisibility adequately, except for the "prerender" use-case (for Chrome only, currently). Implementing an API as a standard so that only one browser can experiment seems premature and unhealthy.

As the working group has discussed on the conference calls, Page Visibility is not a half-attempt at User Idle. Information like page visibility, machine idleness (e.g., CPU usage), user idleness (e.g., user interactions with page), and battery life can all help developers create efficient applications. 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.

Microsoft firmly supports creating a Page Visibility API.

>1. How will PageVisibility affect (or not) certain functionality that "automatically" happens on a page, such as "autoplay" on a video element, or "autofocus" on a <input> box (and there are others which are not JavaScript based)? In those cases, it might be quite desirable to have them not happen until the page is actually rendered/visible (for the input autofocus, it might be an animation that occurs on the focus event, or it might be analytics gathering on the focus event, etc).

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.

> 2. It's obvious that PageVisibility was originally intended as a broader concern than just the prerendering, but it's also clear that the prerendering is (now) a major reason why it's being kept (despite my previous concerns), instead of my proposal to simplify to just the PageIdle approach (which doesn't address the prerendering use-case). Since the two are so closely related, I think it's fair to combine concerns of prerendering as a feature with concerns of PageVisibility itself as an approach.

I disagree. 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. To be clear, the Page Visibility spec does not give the design or specification for prerendering. Page Visibility just reports prerendering as another visibility state, which it is.

Jatinder

Received on Wednesday, 15 June 2011 18:48:12 UTC