Re: Page Visibility Simplifications

I support this simplification, although, as I said on the call, I think it might still be a good idea to spec and keep the `visibilityState` variable, even though it only has the two values (for now). This leaves a better path forward if, in the future, we do decide there's a useful 3rd state to incorporate. I think we could easily say the only two spec'd values are "visible" and "hidden", and any other values (for now) should be vendor-prefixed.

Since I know Chrome is going to keep with their "prerendering" functionality, and thus they'll probably keep the value "prerendered", I think it's a mistake to have the spec not at least define a variable which can hold any such future-considered values.

Also, are we going to keep the event that fires, or are pages required to monitor this variable with a polling setInterval loop or something?

---------

I might also throw out for consideration that, again in nods to what Chrome is going to keep doing with "prerendering", perhaps it would be useful to have a "firstVisible" event that fires, once and only once, when the page is first made visible, to distinguish between that use-case and the throttling use-case of just monitoring the value of the `document.hidden` or `document.visibilityState` variables as the visibility changes back and forth throughout the lifetime of the page.

Without a `firstVisible` event, if I only care to listen for the special "prerendered" and "rendered" state change, then I have to attach an event listener, and once it fires, I have to unattach the listener. But a specific event for that special first state change would make less work on authors (not having to unattach) who only care about delaying for the first-visible state change, and don't care about throttling during page runtime.

`firstVisible` event would have a very symmetric behavior (the run-only-once) to DOMContentLoaded, and I think that would make this whole concept and API easier to explain to web devs.

--Kyle







From: Jatinder Mann 
Sent: Tuesday, June 21, 2011 1:21 PM
To: public-web-perf@w3.org 
Subject: 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