Re: Spec update: deviceorientation event should fire when listener is first registered

Hi,

Thinking about this some more, I was wondering if there's any merit to
the following idea:

- we could have a new "getDeviceOrientation()" method on the navigator
object. This method synchronously returns an object that is an
EventTarget:

var o = navigator.getDeviceOrientation();

- this object is then the target of device orientation events:

o.addEventListener("initial", function(event) { ... });
o.addEventListener("change", function...);
o.addEventListener("error", function...);

This design solves the problem by having the "getDeviceOrientation()"
function be the one that triggers the initial event. I think it also
solves the problem brought up by Bjoern. Furthermore, there is a
precedent for this design in the Indexed Database specification:

http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html#request-api

What do you think?

Thanks,
Andrei



On Wed, Jul 13, 2011 at 7:23 AM, Andrei Popescu <andreip@google.com> wrote:
> On Wed, Jul 13, 2011 at 2:55 PM, Anne van Kesteren <annevk@opera.com> wrote:
>> On Wed, 13 Jul 2011 15:38:18 +0200, Anne van Kesteren <annevk@opera.com>
>> wrote:
>>>
>>> I do not really see how it contradicts it. Setting the attribute does that
>>> *and* causes an event to be dispatched (or starts some process in the case
>>> of MessagePort). The pattern was discussed a while back on the WHATWG list.
>>
>> By the way I am not saying you should use this pattern. Maybe as Björn
>> indicated you need another approach to this API. Have the information
>> hanging off from the Navigator object somewhere and dispatch an event using
>> the basic Event interface when the information has changed.
>>
>
>
> Yep, we should discuss that. The basic issue there is that we'd have
> to keep the information fresh on this object, which means always
> exercising the underlying hardware, even if no page is using it.
>
> Thanks,
> Andrei
>

Received on Thursday, 21 July 2011 17:01:10 UTC