Re: [PageVisibility] Hooks in Unload Processing Model

On 4/3/12 6:02 PM, Jatinder Mann wrote:
>> That's option #1 in my list, isn't it?  If not, how is it different?
>
> It wasn't clear to me that you meant both the event and the attributes not be changed for unload. If so, than my option four is the same as your option 1. :)

OK, good.  Clearly if the hidden state doesn't change when unloading 
there should be no event.  ;)

>> Why is that the goal?  The goal is to determine visibility state.  This is not only used for power- and cpu-efficiency decisions; there are various other use cases (e.g. turning off audio associated with a document, removing event listeners of various sorts, etc, etc).  It's _possible_ to do all this by registering the same event handler for both visibilitychange and pagehide, but it's certainly more complex for developers.
>
> As this spec is chartered in the Web Performance WG, trying to match the specification goals with our charter makes sense. All of the examples you have mentioned (e.g. turning off audio associated with a document, removing event listeners of various sorts, etc) can be tied to reducing unnecessary cpu usage.

No, some of them are basic user-facing correctness behavior and have 
nothing to do with CPU usage...  Those are the ones where getting it 
right on unload matters very much, because the worst case is completely 
incorrect behavior, not just more CPU hogging.

-Boris

Received on Tuesday, 3 April 2012 22:52:41 UTC