- From: Jatinder Mann <jmann@microsoft.com>
- Date: Tue, 3 Apr 2012 22:02:59 +0000
- To: Boris Zbarsky <bzbarsky@MIT.EDU>
- 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>
> 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. :) > Sure. I think at least my opinion is pretty clear; I'd love to hear from others. I'd love to understand how others feel about this as well. > 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. Generally, I understand that doesn't mean an API's usage should be limited to its author's initial goals. Thanks, Jatinder
Received on Tuesday, 3 April 2012 22:03:32 UTC