W3C home > Mailing lists > Public > public-geolocation@w3.org > July 2011

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

From: Andrei Popescu <andreip@google.com>
Date: Tue, 12 Jul 2011 15:02:01 +0100
Message-ID: <CAGn1-_WEtK5KK1M-6nqvyOmW720Wcshcd7Lke_VwkEYamGvxCQ@mail.gmail.com>
To: Wojciech Masłowski <wmaslowski@opera.com>
Cc: Dean Jackson <dino@apple.com>, public-geolocation <public-geolocation@w3.org>, Anne van Kesteren <annevk@opera.com>, Doug Turner <doug.turner@gmail.com>, Steve Block <steveblock@google.com>
On Tue, Jul 12, 2011 at 2:50 PM, Wojciech Masłowski
<wmaslowski@opera.com> wrote:
> W dniu 2011-07-12 15:17, Dean Jackson pisze:
>>
>> On 12/07/2011, at 9:50 PM, Anne van Kesteren wrote:
>>
>>> On Tue, 12 Jul 2011 13:42:36 +0200, Andrei Popescu<andreip@google.com>
>>>  wrote:
>>>>
>>>> On Tue, Jul 12, 2011 at 12:41 PM, Anne van Kesteren<annevk@opera.com>
>>>>  wrote:
>>>>>
>>>>> I think firing when a new listener registers for the event is wrong.
>>>>> Tying that together goes against the event model. addEventListener() has no
>>>>> such side effects.
>>>>
>>>> What exactly is it wrong with it? And what alternative would you
>>>> suggest to solve the given problem?
>>>
>>> You could follow a similar design to http://www.whatwg.org/C#messageport
>>> that does have special handling for onmessage (or here ondeviceorientation),
>>> but not for addEventListener(). If you want to use addEventListener() you
>>> would have to invoke start().
>>>
>>> The problem is that addEventListener() is supposed to be orthogonal to
>>> all this. We could change that, but I am not convinced it is a good idea.
>>
>> I tend to agree with Anne here. We shouldn't change the understood
>> behaviour of addEventListener(). If you really need an event to be fired,
>> then we should expose a mechanism specifically for that.
>>
>> Dean
>>
> Tbh I wouldn't be that religious about it. Requiring browser to fire an
> event after registering a handler solves the problem of registering a
> handler to a non-moving device and doesn't have any specific negative
> implications. Any other solution would mean complicating the API by adding
> some method to force firing of orientation event or in other way getting
> current orientation. From developer point of view it is also simpler this
> way because any other solution forces him to treat initial position as a
> special case.
>

Exactly. IMHO the goal should be to make the developer's life as easy
as possible.

I also think making ondeviceorientation behave differently to
addEventListener() is somewhat unexpected and therefore not a
precedent to be followed?

Thanks,
Andrei


> --
> Wojciech Masłowski
> Engeneering CORE Wrocław
> Opera Software ASA
> http://www.opera.com
>
>
Received on Tuesday, 12 July 2011 14:02:40 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:51:02 UTC