Page Visibility Simplifications

As per discussion in our last conference call, http://lists.w3.org/Archives/Public/public-web-perf/2011Jun/0074.html, the issue was raised that we should consider simplifying the Page Visibility spec by removing the document.visibilityState and relying only on the boolean, document.hidden, that describes whether the page is visible to the eyes or not. This would essentially remove the optional sub-states of PAGE_PREVIEW and PAGE_PRERENDER.

PAGE_PREVIEW: As preview states typically only remain momentarily, it may not make sense for a web developer to differentiate for this scenario. Depending on whether the browser page is visible or not when the preview is shown, this state will be treated as visible or hidden. This simplification would remove the concerns around debouncing.

PAGE_PRERENDER: Per last week's call, it appears that the goal with prerender is that a web developer shouldn't take any explicit action for prerendering. If a web developer wants to take this scenario into account, the developer can still rely on document.hidden - a prerendered page will show up as hidden.

We do not think that any significant functionality will be lost by removing the document.visibilityState.  After removing PAGE_PREVIEW and PAGE_PRERENDER, we are left with PAGE_HIDDEN and PAGE_VISIBLE, which is the same data that document.hidden provides.

As a canonical example of how no functionality is lost, if an ad service only delivers advertisements when the user can visually see the ad, in order to save system resources in downloading ad resources and rendering the ad, this can still be done. On a multi-monitor case, document.hidden will still let the web developer know when the user can view the page, and hence, the ad should be shown.

What are the thoughts on the mailing list in simplifying the Page Visibility spec?

Thanks,
Jatinder

Received on Tuesday, 21 June 2011 18:22:11 UTC