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

RE: Page Visibility Simplifications

From: Jatinder Mann <jmann@microsoft.com>
Date: Wed, 22 Jun 2011 00:05:19 +0000
To: Kyle Simpson <getify@gmail.com>, webperf <public-web-perf@w3.org>
Message-ID: <EE4C13A1D11CFA49A58343DE361B0B04068682B4@TK5EX14MBXC254.redmond.corp.microsoft.com>
I think it's a reasonable point to keep document.visibilityState to reserve the attribute name for optional values or future vendor prefixed visibility states. Other than visible and hidden states, I don't see strong value in keeping the other states; they are currently defined as optional and we may just want to keep them as so.

This spec doesn't define the design or goals behind prerender, so I can't say what the expectations are for a web developer with respect to prerender. Arvind had brought up the point in last week's call that the design of prerender may be such that no action is required from a web developer and a prerender state may not be needed. Arvind, have you had time to consider that proposal?

I wasn't suggesting simplifying the spec to remove the visibilitychange event - that will definitely be needed. The event is currently defined to not fire on registration, but only on visibility change. It might be less confusing to have a single visibilitychange event, even if it requires attaching and unattaching the listener for that one scenario you called out, then two seemingly similar, yet different events. Considering we haven't closed on whether we are to keep or remove prerender, we may want to table for now considering an additional event tailored for the prerender scenario.


From: public-web-perf-request@w3.org [mailto:public-web-perf-request@w3.org] On Behalf Of Kyle Simpson
Sent: Tuesday, June 21, 2011 12:15 PM
To: webperf
Subject: 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.


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

Received on Wednesday, 22 June 2011 00:05:53 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:30 UTC