- From: Steve Block <steveblock@google.com>
- Date: Wed, 29 Jun 2011 18:18:04 +0100
- To: James Graham <jgraham@opera.com>
- Cc: public-geolocation <public-geolocation@w3.org>
Thanks for the comments James. > In general event-listener registration is side-effect free; Hmm, that's a good point. We previously considered having an isCompassCalibrated property, but decided that a separate event is a neater and more standard way of handling the need for the UA to provide a default action. Having discussed this at the recent face-to-face meeting, perhaps we can simply drop the requirement that implementations only fire the compassneedscalibration event when listeners are registered for the deviceorientation event. It keeps things simple and avoids problems with the UA handling multiple browsing contexts with different sets of listeners. I think that the problem of superfluous compassneedscalibration events is very minor. (ISSUE-89 [1]) > "The event must fire at regular intervals" I think the problem here is simply the terminology used in the spec. The intent is that the UA should obtain accelerometer and rotation rate data at a constant frequency. This makes filtering for applications such as gesture recognition much simpler than if the application had to handle a variable update frequency. The purpose of the 'interval' property is to expose this frequency, as a time interval. There was no intention to pose a restriction on the time at which the corresponding event is dispatched to JavaScript. If an implementation chooses to suspend JavaScript events when a browsing context is in the background, that's OK, but the interval property should represent the frequency at which updates are obtained from the hardware. I can update the spec to make this more clear. (ISSUE-90 [2]) If nobody objects, I'll update the spec. Thanks, Steve [1] http://www.w3.org/2008/geolocation/track/issues/89 [2] http://www.w3.org/2008/geolocation/track/issues/90
Received on Wednesday, 29 June 2011 17:18:37 UTC