- From: Wojciech Masłowski <wmaslowski@opera.com>
- Date: Tue, 12 Jul 2011 15:50:13 +0200
- To: Dean Jackson <dino@apple.com>, public-geolocation <public-geolocation@w3.org>
- CC: Anne van Kesteren <annevk@opera.com>, Andrei Popescu <andreip@google.com>, Doug Turner <doug.turner@gmail.com>, Steve Block <steveblock@google.com>
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. -- Wojciech Masłowski Engeneering CORE Wrocław Opera Software ASA http://www.opera.com
Received on Tuesday, 12 July 2011 13:51:04 UTC