- From: Jatinder Mann <jmann@microsoft.com>
- Date: Wed, 16 May 2012 01:09:31 +0000
- To: Arvind Jain <arvind@google.com>, Boris Zbarsky <bzbarsky@mit.edu>
- CC: Sreeram Ramachandran <sreeram@google.com>, "public-web-perf@w3.org" <public-web-perf@w3.org>
> So then, let's settle on calling the visibility handler after pagehide, and also before > pageshow if the page is coming from the pagecache. Also, given that the event is > fired after pagehide, we don't need to overload the visibilityState attribute with > states like "suspended" or "unloaded". So let's remove those two states from >the list (https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/PageVisibility/Overview.html > #dom-document-visibilitystate). > > Please comment if you have any concerns. > > Arvind Regarding ISSUE-8, seems like we have consensus to fire the visibilitychange event after pagehide and before pageshow. I am assuming this also means to fire the visibilitychange event prior to the firing of the unload event? I will make the necessary spec updates to reflect this behavior. About the additional proposed visibiltyState attribute values, I recommend we should at least keep "unloaded". The purpose of the visibilityState attribute is to provide more granular data on the current visibility state than the hidden Boolean does. This state will allow a developer to make an informed decision of whether or not to run additional code during the unload process. I can't see any obvious problems with including this data. Thanks, Jatinder
Received on Wednesday, 16 May 2012 01:10:27 UTC