[Page Visibility] Spec Updates

I have updated the Page Visibility specification draft: http://dvcs.w3.org/hg/webperf/raw-file/tip/specs/PageVisibility/Overview.html.


I have made the following changes:


1.      Window rather than Navigator implements WindowVisibility interface

Per feedback, I have updated the spec to have Window rather than Navigator implement the WindowVisibility interface.



I had initially used Navigator as the window object is used as the global namespace for scripts. Declared variables are of a less concern (e.g., var visible), because the user will notice when they try to read the value that it’s not what they expected. However, undeclared variables (e.g., visible = 0) will fail silently when the user tries to write to them, as visible is defined as a readonly.



Our options are to either create a pageVisible object that lives on Window that contains the two properties, to give descriptive names to the individual properties or to go with the current names and see if there are issues. I don’t prefer the first option, as making an object with only two properties seems like overkill. I recommend we go with the current names and see if there are any major collisions. On a quick crawl of some 2M pages, I only noticed visible used 50 times. We had the same reservations for window.performance, however, it didn’t turn out to be a major problem.



Thoughts?



2.      Event name changed to visibilitychange

I updated the event name to visibilitychange from visibilityChange. I have also specified that this event can only be registered using addEventListener on window; this implies that this event can’t be exposed using onvisibilitychange. Having onvisibilitychange implemented in a library would preclude a page from consuming the event if it is also using the library. This is the same model used by domcontentloaded.



Also, I have specified that the event does not fire on registration; it only fires when visibiltyState has changed after registration.



3.      Visibility definitions generalized

I have generalized the definitions of visibility from my previous very specific cases. I have defined page visibility as the visibility state of the Document contained by the top level browsing context (root window in the browser's viewport). For example, window.visible is true when the Document contained by the top level browsing context (root window in the browser's viewport) is at least partially visible on at least one screen. I have left examples of the specific cases.



4.      Visibility States reduced

I have combined the two preview states to a single PAGE_PREVIEW state. Per Alex’s initial email on page visibility, he had shown interest in a page preview state: http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0175.html



5.      Examples updated

I have updated the example section with more description and an updated example. The updated example is a skeleton case of throttling checking for email when not visible. Let me know if you have any better examples in mind.

Thanks,
Jatinder

Jatinder Mann | Internet Explorer