Re: Device orientation event review comments

On Mon, 6 Jun 2011, Steve Block wrote:

> I've posted an updated editor's draft of the spec which uses normative
> language and the correct formatting -
> http://dev.w3.org/cvsweb/geo/api/spec-source-orientation.html?r1=1.22#rev1.22

That looks like a big improvement, thanks.

I am still slightly concerned about the requirement for the 
compasscalibration event

"This event must only be fired when one or more event listeners are 
registered for the deviceorientation event"

In general event-listener registration is side-effect free; it isn't 
observable whether there is a listener registered for a particular event 
(arguably this is undesirable, but it is a rather fundamental part of the 
model).

I'm not sure what to suggest as the best alternative. One could imagine 
adding a calibrated property to deviceorientation events and allowing the 
user to do something like

if (!e.calibrated) {
   orientation.calibrate();
   return;
}

where window.orientation.calibrate invokes the UA calibration UI. This has 
some pitfalls though since the author would almost-always have to remember 
to return from the event listener after handling the calibration. Also 
multiple event handlers could call the calibration function multiple times 
which might lead to a strange user experience.

Hopefully it's possible to find a good solution to this.

Another possible problem is in the definition of the devicemotion event, 
which says:

"The event must fire at regular intervals"

If that is supposed to mean that the UA is supposed to have exactly X ms 
between each invocation of the event, the requirement is both undesirable 
and unimplementable (consider UAs wishing to fire events less often in 
background tabs, or the behaviour when the computer is placed in 
standby, for example).

I think the right condition is that the event should be fired at a 
UA-defined, and possibly variable, frequency, and that the interval 
property should hold the time in ms between the last time the UA fired a 
devicemotion and the current time (given some sort of monotonic clock; see 
the work being done by the WebPerf WG). In fact such an interval property 
isn't really needed since an author can always register an event handler 
to record the time of the current event and deduce the interval since the 
previous event, but I can see that it can be convenient to provide if most 
usecases require it.

Received on Tuesday, 7 June 2011 18:31:29 UTC