- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Tue, 03 Apr 2012 18:52:10 -0400
- To: Jatinder Mann <jmann@microsoft.com>
- CC: James Graham <jgraham@opera.com>, Ian Hickson <ian@hixie.ch>, "arvind@google.com" <arvind@google.com>, "public-web-perf@w3.org" <public-web-perf@w3.org>
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